curso de engenharia de computação protÓtipo de...
TRANSCRIPT
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
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-property-
functions.html
Acessado em: 03/09/2009
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.
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