Curso de Engenharia de Computação PROTÓTIPO DE …lyceumonline.usf.edu.br/salavirtual/documentos/1674.pdf · Na superfície terrestre um ponto é representado por um valor de latitude

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.

v

.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.

vi

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

vii

Lista de Siglas

OGC Open Geospatial Consortium

KML Keyhole Markup Language

IDE Integrated Development Environment

SIG Sistema de Informação Geográfica

GPS Global Positioning System

PDA Personal Digital Assistants

API Application Interface Programming

SGBD Sistema de Gerenciamento de Banco de Dados

SQL Structure Query Language

TDE Tipos de Dados Espaciais

TCP Transmission Control Protocol

UDP User Datagram Protocol

GPRS General Packet Radio Service

BLOB Large Object

SGBDR Sistema de Gerenciamento de Banco de Dados Relacional

SGBDOR Sistema de Gerenciamento de Banco de Dados Objeto-Relacional

OpenGIS Open Geographic Information System

RAD Rapid Application Development

viii

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

ix

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).

1

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

2

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.

3

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]

4

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]

5

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]

6

Figura 1: Estrutura Geral de Sistema de Informação Geográfica.

3.2 GERÊ9CIA 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;

7

- 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;

8

- 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]

9

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.

10

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.

11

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.

12

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, front-

end, 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.

13

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.

14

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.

15

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.

Figura 9: Interface de configuração.

Região 1

Região 2

Região 3

16

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.

Figura 10: Interface de consulta e análise espacial.

Região 1

Região 2

Região 3

17

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.

18

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

19

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 18: Trecho de código da função

CarregaRegistroGrid que carrega os dados

alfanuméricos de um determinado endereço.

.

Figura 17: Trecho de código da função

CarregaRegistroGrid que carrega os dados de

endereço.

.

20

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]

Figura 19: Interface de consulta exibindo o cálculo de área.

Região 3

21

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.

22

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.

23

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


[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


[4] Open Geospatial Consortium

About OGC

Disponível em: http://www.opengeospatial.org/ogc


[5] Sun Microsystems – MySQL

Spatial Extensions

Disponível em: http://dev.mysql.com/doc/refman/6.0/en/spatial-extensions.html


[6] Sun Microsystems – MySQL

Spatial Extensions – Geometry Functions

Disponível em: http://dev.mysql.com/doc/refman/5.1/en/geometry-property-

functions.html


24

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.




Figura 3: Arquitetura Integrada.




Documents

Curso de Engenharia de Computação PROTÓTIPO DE …lyceumonline.usf.edu.br/salavirtual/documentos/1674.pdf · Na superfície terrestre um ponto é representado por um valor de latitude