1
Antonio da Luz Júnior
PROPOSTA DE UM MODELO DE DISTRIBUIÇÃO DE DADOS
GEOGRÁFICOS ARMAZENADOS EM SGBD SPRING ATRAVÉS DA
WEB
Palmas
2004
2
Antonio da Luz Júnior
PROPOSTA DE UM MODELO DE DISTRIBUIÇÃO DE DADOS
GEOGRÁFICOS ARMAZENADOS EM SGBD SPRING ATRAVÉS DA
WEB
Monografia apresentada como requisito da
disciplina Prática de Sistemas de Informação II
(TCC) do curso de Sistemas de Informação,
orientada pelo Prof. M.Sc. Eduardo Leal.
Palmas
2004
3
ANTONIO DA LUZ JÚNIOR
PROPOSTA DE UM MODELO DE DISTRIBUIÇÃO DE DADOS
GEOGRÁFICOS ARMAZENADOS EM SGBD SPRING ATRAVÉS DA
WEB
Monografia apresentada como requisito da
disciplina Prática de Sistemas de Informação II
(TCC) do curso de Sistemas de Informação,
orientada pelo Prof. M.Sc. Eduardo Leal.
BANCA EXAMINADORA
_______________________________________________
Prof. Ricardo Marx Costa Soares de Jesus
Centro Universitário Luterano de Palmas
_______________________________________________
Prof. M.Sc. Fabiano Fagundes
Centro Universitário Luterano de Palmas
_______________________________________________
Prof. M.Sc. Eduardo Leal
Centro Universitário Luterano de Palmas
Palmas
2004
4
Lista de Figuras
Figura 1: Exemplo de Tipos de Dados que devem ser suportados pelo Modelo de
Dados Geográficos. .............................................................................................5
Figura 2: Modelo de Arquitetura Dual com Banco de Dados Interno. .........................7
Figura 3: Modelo de Arquitetura Dual com Banco de Dados Externo. ........................8
Figura 4: Modelo de Arquitetura Integrada. .................................................................9
Figura 5: Modelo Conceitual SPRING.......................................................................11
Figura 6: Imagem LandSat de Manaus-AM. Exemplo do Tipo de Dados Imagem,
suportado pelo SPRING.....................................................................................13
Figura 7: Mapa de campo magnético, representando o Tipo de Dados Numérico
Suportado pelo SPRING. ...................................................................................13
Figura 8: Mapa de Tipos de Solos. Exemplo do Tipo de Dados Temático, suportado
pelo SPRING......................................................................................................14
Figura 9: O objeto “Rio Yang Tse Kiang” está associado a três mapas distintos.
Exemplo de Geo-Objeto, Tipo de Dados suportado pelo SPRING. ...................14
Figura 10: Geo-Objeto “fazendas” possui ligação com o Objeto Não-Espacial
“cadastro”. Exemplo de Dados Não-Espacial suportado pelo SPRING. ............15
Figura 11: Esquema Conceitual do Modelo de Representação do SPRING.............16
Figura 12: Janela de Visualização do Applet SpringWeb. .........................................18
Figura 13: Janela de Pesquisa do Applet SpringWeb. ..............................................19
Figura 14: Exemplo de uma DTD. .............................................................................20
Figura 15: Exemplo de um documento XML utilizando a DTD da Figura 14. ............20
Figura 16: Exemplo de um documento XSL para o documento XML da Figura 15...21
Figura 17: Exemplo da Iteração entre DTD/XML/XSL/HTML. ...................................21
Figura 18: Modelo de Comunicação do Protocolo SOAP..........................................24
Figura 19: Exemplo de Documento SVG.. ................................................................26
Figura 20: Imagem da Exibição do Documento apresentado na Figura 19. .............27
Figura 21: Exemplo da utilização das geometrias básicas do SVG. .........................28
Figura 22: Geometrias geradas pela Figura 21. ........................................................28
Tabela 1 – Descrição dos Parâmetros dos Comandos do elemento path.................31
Figura 23: Exemplo da utilização dos Comandos path. ............................................32
Figura 24: Gráficos gerados pelo exemplo da Figura 23..........................................33
Figura 25: Camadas do Modelo de Representação. .................................................35
5
Figura 26: Arquitetura Definida para o Modelo Proposto. .........................................38
Figura 27: Exibição do resultado da solicitação feita no passo 4. .............................47
Figura 28: Exibição do resultado da solicitação feita no passo 5. .............................48
Figura 29: Exibição do resultado da solicitação feita no passo 6. .............................49
6
Lista de Tabelas
Tabela 1: Descrição dos Parâmetros dos Comandos do elemento path
31
7
Resumo
Este trabalho apresenta uma Proposta para um Modelo de Distribuição de Dados
Geográficos através da Web. Para que se tenha uma melhor noção das principais
tecnologias envolvidas no processo de representação são fornecidas informações a
respeito dessas tecnologias antes de se apresentar a proposta do trabalho. Além
disso, esse trabalho contém um exemplo da utilização dessa proposta permitindo
uma maior compreensão dos resultados esperados com a utilização desse Modelo
de Representação.
Palavras-Chave: Banco de Dados Geográfico, SIG, SPRING, Web Services, SVG.
8
Abstract
This work presents a Proposal for a Model of Representation of Geographic Data
through the Web.
So that if it has one better notion about the main involved
technologies in the representation process is supplied to information the respect of
these technologies before if presenting the proposal of the work.
Moreover, this work contains an example of the use of this proposal allowing a
bigger understanding of the results waited with the use of this Model of
Representation.
Keywords: Geographic Data Base, GIS, SPRING, Web Services, SVG.
9
SUMÁRIO
1 - INTRODUÇÃO .......................................................................................................1
2. - REVISÃO BIBLIOGRÁFICA.................................................................................3
2.1 – MODELOS DE DADOS .........................................................................................3
2.1.1 - DADOS CONVENCIONAIS ..................................................................................3
2.1.2 – DADOS GEOGRÁFICOS ....................................................................................4
2.2 – SISTEMAS GERENCIADORES DE BANCOS DE DADOS GEOGRÁFICOS ......................5
2.2.1 – Sistemas de Informações Geográficas - SIG ...........................................6
2.2.1.1 – Modelos de Arquitetura......................................................................6
2.2.1.1.1 – Arquitetura Dual ..........................................................................7
2.2.1.1.2 – Arquitetura Integrada ..................................................................8
2.3 - SISTEMA PARA PROCESSAMENTO DE INFORMAÇÕES GEOGRÁFICAS - SPRING ......9
2.3.1. – Armazenamento dos Dados ..................................................................10
2.3.2. – Arquitetura do Sistema..........................................................................10
2.3.4. – Modelo Conceitual.................................................................................11
2.3.5. – Tipos de Dados Suportados ..................................................................12
2.3.6. – Modelo de Representação ....................................................................15
2.3.7. – Interação com o Usuário .......................................................................16
2.3.8. – SpringWeb ............................................................................................18
2.4. - XML (EXTENSIBLE MARKUP LANGUAGE) ..........................................................19
2.5 – W EB SERVICES ..............................................................................................22
2.5.1. - Arquiteturas Existentes ..........................................................................22
2.5.1.1 – Modelo Orientado a Mensagens......................................................23
2.5.1.2 – Modelo Orientado a Serviços...........................................................23
2.5.1.3 – Modelo Orientado a Recursos .........................................................23
2.5.1.4 – Modelo Orientado a Políticas...........................................................23
2.5.2 - SOAP ......................................................................................................24
2.5.3 - WSDL......................................................................................................25
2.6 – SVG (SCALABLE VECTOR GRAPHICS) ..............................................................25
2.6.1. – Estrutura do Documento .......................................................................26
2.6.2. – Geometrias Básicas ..............................................................................27
2.6.2.1. – Retângulo .......................................................................................29
10
2.6.2.2. – Linha ...............................................................................................29
2.6.2.3. – Polígono .........................................................................................29
2.6.2.4. – Círculo ............................................................................................30
2.6.2.5. – Elipse ..............................................................................................30
2.6.3. – Elemento Path.......................................................................................30
3 – RESULTADOS E DISCUSSÕES........................................................................34
3.1 – CONSIDERAÇÕES INICIAIS ................................................................................34
3.2. – APRESENTAÇÃO DO MODELO DE REPRESENTAÇÃO DE DADOS GEOGRÁFICOS ....34
3.3 – CAMADAS DO MODELO ....................................................................................35
3.3.1 – Aplicação Cliente....................................................................................36
3.3.2 – Web Services .........................................................................................36
3.3.3 – SGBDG SPRING....................................................................................37
3.4 – ARQUITETURA DO MODELO .............................................................................37
3.4.1 – Funcionamento da Arquitetura ...............................................................38
3.4.1.1 – Usuário ............................................................................................39
3.4.1.2 – Navegador Web...............................................................................39
3.4.1.3 – Aplicação .........................................................................................40
3.4.1.4 – Métodos ...........................................................................................40
3.4.1.4.1 – Ativar/Desativar Banco de Dados .............................................41
3.4.1.4.2 – Ativar/Desativar Projeto.............................................................41
3.4.1.4.4 – Classes necessárias à transição dos dados .............................42
3.4.1.4.5 – Buscar Categorias e Planos de Informações ............................44
3.4.1.4.6 – Exibir Mapa ...............................................................................44
3.4.1.5 – Web Services...................................................................................45
3.4.1.6 – SGBDG............................................................................................45
3.4.1.7 – Dados ..............................................................................................45
3.4.1.8 – Resultado Solicitação ......................................................................46
3.4.1.9 – SVG .................................................................................................46
3.5 – EXEMPLO DE UTILIZAÇÃO DA PROPOSTA ............................................................46
3.6 – CONSIDERAÇÕES FINAIS .................................................................................49
4 – CONCLUSÃO .....................................................................................................50
5 - BIBLIOGRAFIA ...................................................................................................51
1
1 - Introdução
As tecnologias existentes (entre as quais se encontram ferramentas como Java)
estão possibilitando inovações na maneira como é feito o acesso à informação
geográfica. De um lado, têm-se grandes bancos de dados espaciais, com
mecanismos eficientes de acesso e busca da informação. Na outra ponta, uma
interface amigável permitindo a fácil navegação pelos dados, sem a necessidade de
montar um banco de dados local e converter os dados de outro sistema.
Devido à deficiência atualmente encontrada para se trabalhar com dados
geográficos de forma compartilhada surgiu a iniciativa de desenvolver uma proposta
de compartilhamento desses dados de forma a permitir a maior utilização das
informações geográficas existentes em um determinado banco de dados. Evita-se
com isso a necessidade da replicação desse banco para que possa ser utilizado por
outra pessoa ou entidade.
A
idéia
apresentada
por
CAMARA
(1996)
acrescentou
um
maior
embasamento sobre a necessidade do desenvolvimento dessa proposta e permitiu a
visualização de algumas funcionalidades que poderiam ser inseridas ao modelo
proposto.
O objetivo principal dessa proposta é auxiliar na elaboração de ferramentas
para distribuição de dados geográficos. Com isso o desenvolvedor passa a ter uma
visão geral do funcionamento das tecnologias e conhecer os passos que devem ser
seguidos para estabelecer a comunicação entre o usuário e o gerenciador de banco
de dados.
Para o desenvolvimento desse trabalho inicialmente foi realizado um estudo a
respeito do armazenamento dos dados geográficos e das formas existentes para
possibilitar o compartilhamento de informações através da Web, para que se
pudesse ter uma visão geral das tecnologias passíveis de serem utilizadas durante o
decorrer do desenvolvimento da proposta.
2
Após o levantamento inicial definiu-se pela utilização do Sistema para
Processamento de Informações Geográficas – SPRING, para gerenciar os dados
armazenados, além da utilização de Web Services para permitir o acesso dos
usuários aos dados armazenados através da Web. Para possibilitar a visualização
gráfica dos dados retornados do SPRING por parte do usuário, optou-se pela
utilização do padrão gráfico Scalable Vector Graphics - SVG.
Inicialmente esse trabalho irá apresentar uma Revisão Bibliográfica a respeito
das
tecnologias
a serem
utilizadas
no desenvolvimento da proposta. E,
posteriormente, será apresentada a proposta do modelo de representação dos
dados geográficos, bem como sua arquitetura e maiores explicações sobre as
funcionalidades a serem implementadas nos métodos que serão disponibilizados
pelo Web Services.
3
2. - Revisão Bibliográfica
Este capítulo apresenta alguns conceitos básicos relativos aos Modelos de Dados,
Sistemas Gerenciadores de Banco Geográficos (SGBD), Sistemas de Informações
Geográficas (SIG) e demais tecnologias utilizadas para composição da proposta
apresentada neste trabalho.
2.1 – Modelos de Dados
Um modelo é uma abstração de alguma coisa, cujo propósito é permitir que se
conheça essa coisa antes de se construí-la (RUMBAUGH, 1994).
Modelo de dados é uma coleção de ferramentas conceituais para descrição
dos dados, relacionamento entre os dados, semântica e restrições dos dados
(SILBERSCHATZ, 1999).
Conhecer os tipos de modelos de dados existentes é de fundamental
importância para o desenvolvimento ou manipulação de bancos de dados, sejam
eles: Relacional, Orientado a Objetos ou Pós-Relacional. Isso permite que o
desenvolvedor/manipulador desses dados tenha conhecimento das operações
possíveis de serem realizadas com os dados pertencentes a um determinado
modelo ou ainda, saiba qual o formato dos dados que podem ser armazenados
através de um modelo.
2.1.1 - Dados Convencionais
Os modelos ou tipos de dados convencionais são o conjunto das formas básicas de
dados existentes num ambiente computacional. Essas formas básicas são formadas
por cadeias de números ou textos. São, geralmente, representados em SGBD’s
através dos tipos:
4
•
String: identifica uma cadeia de caracteres, formada por textos ou números;
•
Integer: identifica um número inteiro;
•
Real: identifica um número decimal.
A partir desses tipos básicos de dados podem ser formados outros modelos
de dados que serão utilizados para o armazenamento de dados mais complexos. Os
SGBD’s, geralmente, fornecem aos usuários alguns modelos de dados que se
adequam ao armazenamento de dados complexos pertencentes a domínios
específicos. Além disso, o usuário pode ou não ter a possibilidade de definir seus
próprios modelos de dados para que melhor se adapte ao domínio abordado de
acordo com a disponibilidade do SGBD utilizado.
2.1.2 – Dados Geográficos
Os Dados Geográficos, ou Espaciais, possuem características que os tornam
complexos de serem representados, principalmente por terem que manter uma
estrutura particular e muitos relacionamentos espaciais. Por isso esse tipo de dados
não é suportado pelos modelos de dados convencionais, sendo necessária a
definição de novos modelos capazes de suportar suas características.
BORGES
(1996)
apresenta
alguma
das
características
dos
Dados
Geográficos dizendo que um Modelo de Dados Geográfico deve ser capaz de:
a) Representar os diferentes tipos de dados: espaciais (ponto, linha,
polígono), imagens (mapas, modelo digital de terreno) e dados alfanuméricos;
b) Suportar relacionamentos espaciais;
c) Ser independente da implementação;
d) Representar a forma gráfica dos objetos.
As características particulares dos Dados Geográficos são a razão pela qual
se faz necessário estruturar novos tipos de dados e arquitetar novas formas de
armazenamento e acesso aos dados (SILVA, 2002).
Os dados espaciais são constituídos pela combinação de um ou vários
conjuntos de (X,Y) ou (X,Y e Z) para representarem a localização espacial de um
objeto no mundo real (LUZ, 2004).
Os objetos representados por estes tipos de dados podem ser desde um
poste de energia localizado na rua de uma determinada cidade (ponto), ou mesmo a
5
própria cidade dentro de um mapa cartográfico do estado no qual ela se situa
(polígono), dependendo do domínio de informação ao qual pertençam. Na Figura 1
pode se observar alguns dos tipos de dados que devem ser suportados pelo modelo
espacial.
Para determinarmos a qual domínio os dados espaciais se referem, faz-se
necessário que estes estejam conectados a metadados (LUZ, 2004), dado ou
conjunto de dados que servem para descrever outros dados, surgindo a
necessidade de se integrar à utilização de dados espaciais com Bancos de Dados
que possuam as informações descritivas sobre os mesmos.
Figura 1: Exemplo de Tipos de Dados que devem ser suportados pelo Modelo de
Dados Geográficos.
2.2 – Sistemas Gerenciadores de Bancos de Dados Geográficos
Os SGBD’s Geográficos herdam todas as características impostas para os SGBD’s
Objeto-Relacional (extensão de tipos de dados, suporte a objetos complexos,
herança, regras, dentre outras que podem ser vistas em LUZ (2004)) por se tratar de
6
uma especialização deste paradigma, ou seja, os SGBD’s Geográficos são SGBD’s
Objeto-Relacional destinados ao armazenamento nativo de dados espaciais.
Um SGBD Geográfico é responsável pelo armazenamento e recuperação dos
dados, permitindo que os dados sejam identificados através de suas extensões e
posicionamentos espaciais, além de manter a consistência.
2.2.1 – Sistemas de Informações Geográficas - SIG
Os primeiros Sistemas de Informações Geográficas, SIG, não foram projetados para
darem suporte a dados alfanuméricos. Foram desenvolvidos para prover análise
espacial, visualização cartográfica, não dando tanta importância em oferecer
recursos de banco de dados (REEVE, 2001).
Os Sistemas de Informações Geográficas são uma forma comum de utilização
de SGBD’s Geográficos. Consistem em aplicações que armazenam ou recuperam
dados nesses SGBD’s e possuem uma ferramenta que permite a análise dos dados
espaciais armazenados.
A necessidade de integração de dados espaciais com dados convencionais
foi uma preocupação posterior ao desenvolvimento das ferramentas SIG. A essa
necessidade deve-se a existência de diferentes arquiteturas de bancos de dados
geográficos. Essa integração é importante, senão fundamental, porque permite a
análise conjunta de vários tipos de informações e onde elas ocorrem no espaço
(SILVA, 2002).
2.2.1.1 – Modelos de Arquitetura
Existem dois modelos distintos de arquitetura de SIG’s: uma denominada Dual que
armazena os dados espaciais e convencionais em locais diferentes e mantêm um
identificador único para cada objeto comum as duas bases; e outra, denominada
Integrada, que armazena os dados de forma conjunta, utilizando para tal um sistema
gerenciador próprio para manipular esse novo tipo de dados.
7
2.2.1.1.1 – Arquitetura Dual
O modelo de Arquitetura Dual tenta solucionar o problema de gerenciamento de
dados geográficos integrando os dados convencionais e espaciais, armazenados em
bases de dados distintas, através de identificadores comuns as duas bases (LUZ,
2004).
O modelo Dual apresenta duas formas possíveis de utilização da base de
dados convencional: integrante da ferramenta SIG, exemplo apresentado na Figura
2, ou como uma base de dados externa a ferramenta SIG, conforme apresentado na
Figura 3, conectando-se a ferramenta através de software utilizado para esse fim.
SILVA (2002) diz que a utilização da segunda abordagem permite uma maior
flexibilidade ao usuário, possibilitando que esse escolha a base de dados
convencional a ser utilizada.
A arquitetura Dual possui um ponto fraco, que é a dificuldade em garantir a
integridade entre as partes geométrica e descritiva da representação do objeto
geográfico (LUZ, 2004). Na maioria dos casos, existe a possibilidade de um usuário
desavisado acessar o banco de dados alfanumérico e modificar algo sem que a
estrutura de dados geográficos tenha conhecimento do fato (DAVIS, 2001).
Figura 2: Modelo de Arquitetura Dual com Banco de Dados Interno (SILVA, 2002).
8
Figura 3: Modelo de Arquitetura Dual com Banco de Dados Externo (SILVA, 2002).
2.2.1.1.2 – Arquitetura Integrada
Um outro modelo de arquitetura possível para ferramentas SIG é o modelo
Integrado, que utiliza SGBD Objeto-Relacional, possibilitando a integração dos
dados espaciais e alfanuméricos. Esta integração é permitida por uma característica
existente nos SGBD’s Objeto-Relacionais de oferecem suporte a manipulação de
dados complexos e a criação de novos tipos de dados. A Figura 4 apresenta um
exemplo de utilização dessa Arquitetura.
Devido a isso os dados espaciais beneficiam-se das características dos
SGBD’s Convencionais, que na arquitetura Dual eram desfrutadas apenas pelos
dados descritivos: integridade, segurança, backup e recuperação dos dados (LUZ,
2004).
A abordagem Integrada assegura uma forte ligação entre os dados espaciais
e os dados não-espaciais, reduzindo a dificuldade de se manter a integridade dos
dados (SILVA, 2002), solucionando outra dificuldade apresentada pelo modelo Dual.
O modelo Integrado apresenta ainda outra grande vantagem em relação ao
modelo Dual: por armazenar os dados em uma mesma base, o processo de consulta
fica facilitado, sendo necessário realizar um único acesso a base para retornar os
dados desejados. Na arquitetura Dual, para se retornar a localização de um objeto e
sua descrição eram necessários dois acessos as bases, um para a base espacial e
outro para a convencional.
9
Figura 4: Modelo de Arquitetura Integrada (SILVA, 2002).
2.3 - Sistema para Processamento de Informações Geográficas - SPRING
O SPRING começou a ser desenvolvido no início da década de 90, no INPE
(Instituto
Nacional
de
Pesquisas
Espaciais),
pelo
DPI
(Departamento
de
Processamento de Imagem) como uma proposta de atualização dos sistemas
anteriormente desenvolvidos por este Instituto, SITIM/SGI.
O SITIM/SGI até o presente momento tinha suprido as necessidades básicas
do processamento de dados espaciais. Porém, com o surgimento de ambientes
baseados em janelas esses sistemas não conseguiriam sobreviver sem que
passassem por um processo de atualização.
O ambiente SPRING foi proposto visando unificar o tratamento de imagens de
Sensoriamento Remoto (ópticas e microondas), mapas temáticos, mapas cadastrais,
redes e modelos numéricos de terreno (CÂMARA, 1996).
Baseado em um modelo de dados orientado a objetos, o SPRING combina as
idéias de "campos" e "objetos geográficos", atingindo grandes resultados em
integração de Dados (NCGIA, 1989; GOODCHILD, 1992; COUCLELIS, 1992;
WORBOYS, 1995).
Na proposta de desenvolvimento do SPRING ainda estão presentes duas
outras características importantes, como:
•
ambiente multiplataforma: permitindo a compatibilidade com as diversas
versões do UNIX e MS/Windows;
•
interface amigável: desenvolvendo uma interface simples, como a utilizada
pelo SITIM/SGI, permitindo uma fácil utilização pelos usuários.
A primeira versão do SPRING, liberada para a utilização de entidades
externas ao INPE, foi concluída em dezembro de 1994, já permitindo a realização de
estudos ambientais importantes (ALVES, 1996). Atualmente o SPRING encontra-se
em sua 4ª versão e está disponível para download em SPRINGa (2004).
10
2.3.1. – Armazenamento dos Dados
O banco de dados geográfico construído pelo SPRING implementa uma arquitetura
Dual onde as representações dos dados espaciais e as informações descritivas
(dados não espaciais) são armazenados em ambientes diferentes (THOMÉ, 1998) e
permite ao usuário optar por qual formato de arquivo utilizar para armazenar as
informações. Na sua versão atual estão disponibilizados os formatos DBase, Access,
Oracle e MySQL.
2.3.2. – Arquitetura do Sistema
O ambiente SPRING é composto por três módulos que realizam funções específicas,
porém são complementares para a composição do ambiente inicialmente proposto
pelo DPI/INPE. Em THOMÉ (1998) esses módulos são descritos da seguinte
maneira:
2.3.3.1. – IMPIMA
Este módulo é o responsável pela conversão das imagens obtidas nos formatos
BSQ, Fast Format, BIL e 1B para o formato GRIB (Gridded Binary).
Estas imagens podem ser obtidas através de dispositivos CD-ROM, CCT
(Computer Compatible Tapes), Streamer (60 ou 150 megabytes) e DAT (Digital
Audio Tape - 4 ou 8mm) adquiridas a partir dos sensores TM/LANDSAT-5,
HRV/SPOT e AVHRR/NOAA.
2.3.3.2. – SCARTA
O módulo SCARTA permite a edição de cartas geográficas e gera arquivos para
impressão a partir de resultados gerados no módulo principal do sistema, módulo
SPRING.
Esse módulo possibilita ainda a edição de textos, símbolos, legendas, linhas,
quadros e grades em coordenadas planas ou geográficas. Além disso, permite a
exibição de mapas em várias escalas, através do recurso WYSIWYG (What You See
Is What You Get - O que você vê é o que você tem).
11
2.3.3.3. – SPRING
Esse é o módulo principal do sistema e permite a entrada, manipulação e
transformação de dados geográficos, executando as funções relacionadas à criação,
manipulação e consulta ao banco de dados. Além disso, permite o processamento
digital de imagens, modelagem numérica de terreno e análise geográfica de dados.
2.3.4. – Modelo Conceitual
O SPRING utiliza o modelo de Arquitetura Dual para prover o armazenamento dos
dados, porém, conceitualmente a realidade geográfica é representada por um
modelo conceitual baseado do paradigma Orientado a Objetos (THOMÉ, 1998).
O Modelo Conceitual do SPRING é traçado por THOMÉ (1998) e adaptado
em SILVA (2002), Figura 5, após uma pesquisa efetuada através de questionário e
conversas com os desenvolvedores do sistema.
Figura 5: Modelo Conceitual SPRING (SILVA, 2002).
12
O Banco de Dados Geográfico é composto por Projeto ou Projetos e por
Categoria ou Categorias que devem ser definidos pelo usuário. Cada Projeto possui
Plano de Informação, ou Planos de Informações, pertencente a uma Categoria.
Cada Categoria só pode ter um Plano de Informação (SILVA, 2002). Uma Categoria,
por sua vez, pode ser especializada em Campos ou Geo-Campos, Mapa de Objetos
ou Não-Espacial.
Um Geo-Campo representa a distribuição espacial de uma variável que
possui valores em todos os pontos pertencentes a uma região geográfica (SPRINGb,
2004) e podem ser especializados em Temático, Numérico ou Imagens.
Um Mapa de Objetos armazena o objeto em conjunto com seus vizinhos
mantendo as relações de topologia (SILVA, 2002). Podem ser especializados em
Cadastral ou Rede. Os Objetos armazenados pelos Mapas de Objetos mantêm
relação com uma Tabela de Atributos descritivos sobre eles.
A Categoria do modelo Não-Espacial refere-se aos dados que não possuem
representação espacial como, por exemplo, os dados de cadastros rurais e urbanos
(SPRINGb, 2004).
2.3.5. – Tipos de Dados Suportados
Os Dados suportados SPRING são definidos a partir de derivações e relações do
Modelo Conceitual definido pelo ambiente em um dos tipos abaixo:
•
Imagem:
− Armazenam os dados provenientes de Sensoriamento Remoto, em formato
matricial. A Figura 6 apresenta um exemplo de imagem suportada por este
tipo;
13
Figura 6: Imagem LandSat de Manaus-AM. Exemplo do Tipo de Dados Imagem,
suportado pelo SPRING (SPRINGb, 2004).
•
Numérico:
− Dados que possuem uma variação contínua de seus valores numéricos em
função de sua posição na superfície (SPRINGb, 2004). A Figura 7 apresenta
um exemplo de representação de dados suportados por este tipo;
Figura 7: Mapa de campo magnético, representando o Tipo de Dados Numérico
Suportado pelo SPRING (SPRINGb, 2004).
14
•
Temático:
− Representam a classificação de uma posição geográfica quanto a um
determinado tema. A Figura 8 apresenta um exemplo de representação de
dados suportado por este tipo;
Figura 8: Mapa de Tipos de Solos. Exemplo do Tipo de Dados Temático, suportado
pelo SPRING (SPRINGb, 2004).
•
Objeto:
− É um elemento único que possui dados descritivos (tabela de atributos) nãoespaciais e está associado a múltiplas localizações geográficas (SPRINGb,
2004). A Figura 9 apresenta um exemplo de representação de dados
suportado por este tipo;
Figura 9: O objeto “Rio Yang Tse Kiang” está associado a três mapas distintos.
Exemplo de Geo-Objeto, Tipo de Dados suportado pelo SPRING (SPRINGb, 2004).
15
•
Cadastral:
− Utilizado para representar Mapas de Objetos que contêm a representação de
determinado tipo de objeto, por exemplo: Divisão política é a categoria
cadastral que conterá o mapa com as representações dos municípios
(SPRINGb, 2004);
•
Rede:
− Representa os dados geográficos que possuem relações de fluxo e conexão
entre os inúmeros elementos representados. Ex: rede de energia elétrica,
esgoto, água, drenagem, telefonia, etc (SPRINGb, 2004);
•
Não-Espacial:
− Engloba qualquer tipo de informação que não seja georeferenciada e que se
queira agregar a um SIG. A Figura 10 apresenta um exemplo de
representação de dados suportado por este tipo.
Figura 10: Geo-Objeto “fazendas” possui ligação com o Objeto Não-Espacial
“cadastro”. Exemplo de Dados Não-Espacial suportado pelo SPRING (SPRINGb,
2004).
2.3.6. – Modelo de Representação
O SPRING possui modelo de representação gráfica para os tipos de dados
vetorial e matricial (THOMÉ, 1998). A representação vetorial, do objeto espacial ou
16
campo, é implementada usando as geometrias básicas: pontos, linhas ou polígonos.
A representação matricial utiliza um dos métodos de grade: regular ou triangular
irregular.
Figura 11: Esquema Conceitual do Modelo de Representação do SPRING. Extraído de
(THOMÉ, 1998).
A Classe Visual apresentada na Figura 11 representa as propriedades
definidas pelo usuário para apresentação dos dados da Categoria Temático. Classes
Temáticas, ou Visual, definem o modo como pontos, linhas e áreas serão
apresentadas no monitor (cor, hachura, preenchimento, etc) (THOMÉ, 1998).
2.3.7. – Interação com o Usuário
Para iniciar a utilização do sistema SPRING, módulo principal, o usuário deverá
indicar o diretório no qual se encontra o banco de dados que deseja manipular, ou
então, criar um novo banco de dados, repassando para o sistema o nome do banco
e um caminho (path) onde o banco será criado.
Caso o usuário deseje criar um novo banco, será criado então no caminho
indicado um sub-diretório com o nome atribuído ao banco. Esse diretório
corresponde fisicamente ao banco de dados do SPRING. Tudo que for criado e
definido para este banco será armazenado debaixo deste diretório (THOMÉ, 1998).
Depois de criar um novo banco de dados ou indicar o caminho de um banco
existente, é necessário ativar o banco de dados para que possa manipular as
17
informações contidas nele. Somente um banco de dados pode estar ativo de cada
vez (THOME, 1998).
Após definir um banco de dados como ativo, caso seja um novo banco, é
necessário definir algumas Categorias e Classes Temáticas, para que cada tipo de
dado existente no Banco esteja associado a uma Categoria.
Classes Temáticas são subcategorias dos dados Temáticos e definem o
modo como pontos, linhas e áreas serão apresentadas na tela (cor, hachura,
preenchimento, etc) (THOMÉ, 1998).
Depois de definido ou criado o banco de dados com o qual se irá trabalhar, é
necessário definir a área física de trabalho, ou simplesmente, um Projeto dentro do
banco. Podem-se criar quantos Projetos forem necessários para cada banco de
dados, mas apenas um poderá estar ativo por vez (THOMÉ, 1998).
Ao criar um Projeto o usuário precisa fornecer ao sistema um nome, uma
projeção e o retângulo envolvente, que corresponde à área do Projeto. Fisicamente
um Projeto corresponde a um subdiretório criado dentro do diretório do Banco de
Dados, e todos os dados referentes a região do Projeto serão armazenados dentro
desse diretório.
Após a definição do Projeto, ou Projetos, dentro do Banco de Dados, devemse definir os Planos de Informações que são pertencentes a um determinado Projeto
e representam os diversos tipos de mapas(solos, estradas, etc) ou imagens, que se
encontram na mesma área geográfica pertencente ao retângulo envolvente definido
para o Projeto.
Para se criar um Plano de Informações deve-se fornecer um nome, uma
Categoria (definida anteriormente), uma escala (se for um Plano de Informação
Temático, Numérico ou Cadastral) e a resolução (caso seja um Plano de Informação
Numérico ou Imagem) (THOMÉ, 1998).
Os dados no SPRING podem ser obtidos nos formatos vetorial ou matricial.
Os dados matriciais podem ser obtidos através da edição de pontos, linhas e áreas
utilizando uma mesa digitalizadora, ou conversão de arquivos de outros softwares.
Para obtenção de dados matriciais pode-se utilizar leitura de imagens em formatos
suportados pelo sistema, interpolação de matrizes ou, ainda, conversão de dados
vetoriais.
18
2.3.8. – SpringWeb
Basicamente o SpringWeb é um applet orientado para a visualização de dados
geográficos. Ele é composto por uma janela principal (Janela do Mapa) e por
diversas janelas auxiliares (NING, 2000).
O SpringWeb permite a visualização, figura 12, e a construção de consultas,
figura 13, sobre dados exportados de um Banco de Dados SPRING e convertidos
para o formato aceito pelo SpringWeb. Essa conversão é oferecida pelo módulo
principal do ambiente SPRING.
Figura 12: Janela de Visualização do Applet SpringWeb (NING, 2000).
19
Figura 13: Janela de Pesquisa do Applet SpringWeb (NING, 2000).
O SpringWeb oferece diversas funcionalidades, permitindo ao usuário
manipular dados oriundos de um Banco de Dados SPRING, sem necessariamente
possuir os módulos do ambiente SPRING instalados localmente. Esses dados
podem ser, posteriormente, convertidos novamente para o formato do SPRING e
inseridos no Banco de Dados.
2.4. - XML (Extensible Markup Language)
XML (eXtensible Markup Language) é um formato padrão estabelecido pela W3C
(World Wide Web Consortium) para representação de dados estruturados e
semiestruturados na Web (QUEIROZ, 2002). A XML originou-se a partir da SGML
(Standard Generalized Markup Language), padrão para armazenamento e
intercâmbio de informações e dados em todo o mundo, adotado em 1986 (KIRK,
2000).
Linguagens de marcação são linguagens que descrevem a estrutura de um
documento, ou seja, como estão dispostas as informações do documento (COELHO,
2004). A XML é uma linguagem de marcação que permite ao usuário a criação de
marcações próprias e fornece a descrição das estruturas de dados criadas através
da DTD e Schema (formas utilizadas para descrever a estrutura de um documento
20
XML). Devido a essa característica, tem se tornado uma linguagem universalmente
utilizada para resolver problemas de intercâmbios de.
O documento XML é constituído de três partes distintas:
•
Estrutura: define como os dados estarão dispostos no documento. Não é
necessária a definição de uma estrutura para a construção de um documento;
•
Conteúdo: documento XML propriamente dito, contém os dados que se
deseja representar. Mesmo que não exista uma estrutura pré-definida para
um documento, os dados contidos nele devem ser apresentados dentro de
tags, marcações definidas pelo usuário, que servem para identificar o
tipo/característica dos dados;
•
Apresentação: define a forma de apresentação do documento XML. Pode ser
definida através de XSL (Extensible Stylesheet Language) ou CSS
(Cascading Style Sheets) que são padrões utilizados para definir como os
dados serão exibidos para o usuário através do navegador Web.
<!ELEMENT empregados (empregado+)>
<!ELEMENT empregado (nome+, endereço+)>
<!ELEMENT nome (#PCDATA)>
<!ELEMENT endereco (#PCDATA)>
Figura 14: Exemplo de uma DTD.
A Figura 14 apresenta uma DTD de um cadastro de empregados de uma
empresa. Esse exemplo traz uma tag principal empregados que é composta por uma
ou mais tags empregado, que por sua vez é formada por duas tags, nome e
endereço, armazenam dados do tipo PCDATA, que representam uma cadeia de
caracteres alfanuméricos.
<empregados>
<empregado>
<nome>Maria Aparecida</nome>
<endereco>Rua Terra, 13</endereco>
</empregado>
<empregado>
<nome>Jonas Silva</nome>
<endereco>Av. Afonso Pena, 1305</endereco>
</empregado>
<empregado>
<nome>Carlos Roberto</nome>
<endereco>Rua Taberna, 200</endereco>
</empregado>
</empregados>
Figura 15: Exemplo de um documento XML utilizando a DTD da Figura 14.
21
Na Figura 15 é apresentado um trecho de um documento XML que utiliza a
estrutura definida na DTD apresentada na Figura 14. Esse trecho contem os nomes
e endereços dos empregados.
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"
xmlns="http://www.w3.org/TR/REC-html40">
<xsl:template match="/">
<html>
<body>
<table border="1">
<tr>
<td><b>Nome</b></td>
<td><b>Idade</b></td>
</tr>
<xsl:for-each select="//empregado" order-by="nome">
<tr>
<td><xsl:value-of select="nome" /></td>
<td><xsl:value-of select="endereco"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Figura 16: Exemplo de um documento XSL para o documento XML da Figura 15.
A Figura 16 mostra um exemplo de um documento XSL utilizado para
exibição do documento XML apresentado na Figura 15. Com esse exemplo é criada
uma tabela onde serão apresentados os dados existentes no documento, buscando
a partir das tags empregado, ordenando os resultados pela tag nome.
A Figura 17 apresenta um esquema encontrado em QUEIROZ (2002)
mostrando a iteração existente entre DTD, XML, XSL e HTML.
Figura 17: Exemplo da Iteração entre DTD/XML/XSL/HTML (QUEIROZ, 2002).
22
2.5 – Web Services
Um Web Services é uma aplicação que é acessível por programas através de
protocolos Web de uma forma independente de plataforma (KALANI, 2002). Em
(SOUZA, 2003) é apresentado um maior detalhamento da descrição feita por
(KALANI, 2002):
a) “aplicação acessada por programas através de protocolos web”:
essa
proposta não é nova, ou seja, não surgiu com o Web Services. Anteriormente
a essa tecnologia outras, como DCOM e CORBA já permitiam a execução de
métodos remotos através das Internet;
b) “independente de plataforma”: essa proposta sim, demonstra a importância da
utilização de Web Services. Por utilizar a XML para comunicação entre as
aplicações, Web Services permite que uma aplicação, independente de sua
plataforma de desenvolvimento, consiga acessar remotamente os métodos
disponibilizados por ele.
Uma outra definição para Web Services é encontrada em (LINHADE
CODIGOa, 2004) onde diz que: um Web Services é um conjunto de métodos
WebMethods logicamente associados e chamados através de SOAP (protocolo
utilizado para troca de mensagens). Os WebMethods são funções chamadas
remotamente através de SOAP. Nessa definição é importante ressaltar que nem
todos os métodos necessitam ser do tipo WebMethod.
2.5.1. - Arquiteturas Existentes
A arquitetura de um Web Services não define como ele será implementado. Uma
arquitetura de Web Services define algumas das suas características, identificando
os elementos e serviços Web globais que devem ser seguidos para manter a
interoperabilidade (W3Cb, 2004). Por causa da característica de interoperabilidade,
Web Services podem comunicar entre si mesmo possuindo modelos de arquiteturas
diferentes.
Um Web Services pode ser construído de acordo com as características
propostas para um dos quatro diferentes modelos de arquitetura existentes:
Orientado a Mensagens, Orientado a Serviços, Orientado a Recursos ou Orientado a
Políticas.
23
2.5.1.1 – Modelo Orientado a Mensagens
O Modelo Orientado a Mensagens, como o próprio nome sugere, tem seu foco
voltado para a transmissão de mensagens e na forma em que estas são
processadas (W3Cb, 2004). Preocupa-se mais com a estrutura e a forma com que
uma mensagem é transmitida do que com o seu conteúdo ou significado.
Segundo (W3Cb, 2004), a essência de um Web Services baseado no modelo
orientado à mensagens pode ser resumida através da ilustração de alguns
conceitos-chave: o agente é quem envia e recebe mensagens, a estrutura das
mensagens é formada por cabeçalho e corpo e possui um mecanismo responsável
pelo envio das mensagens.
2.5.1.2 – Modelo Orientado a Serviços
O Modelo Orientado a Serviços preocupa-se com os serviços e com as ações,
podendo ser definido através do relacionamento entre o agente e os serviços
(oferecidos ou requisitados) (W3Cb, 2004).
Segundo W3Cb (2004), a essência de um Web Services baseado no modelo
orientado à serviços também pode ser resumida através da ilustração de conceitoschave: um serviço é oferecido por um agente (provider) e acessado por um outro
agente (requester).
2.5.1.3 – Modelo Orientado a Recursos
O Modelo Orientado a Recursos preocupa-se com algumas das características
principais
dos
recursos,
tais
como
posse
e
políticas
dos
recursos,
independentemente do papel que o recurso tem no contexto do Web Services.
(W3Cb, 2004).
2.5.1.4 – Modelo Orientado a Políticas
O Modelo Orientado a Políticas preocupa-se com as restrições existentes no
relacionamento entre agentes e serviços (W3Cb, 2004). As Políticas também podem
ser definidas para restringir as operações sobre os serviços. As políticas podem ser
24
utilizadas para representar os aspectos de segurança, de qualidade do serviço e da
gerência da aplicação (W3Cb, 2004).
2.5.2 - SOAP
O SOAP, Simple Object Access Protocol, é um formato de mensagens baseado em
XML, usado para transmitir informações entre duas localidades ou “extremidades”
(SOUZA, 2003).
Cada mensagem SOAP constitui um “envelope” que pode ser
formada por um cabeçalho, que é opcional e descreve informações como data de
envio e identificação do remetente e por um corpo, que possui o conteúdo da
mensagem propriamente dito (W3Cc, 2004).
Uma mensagem SOAP é fundamentalmente utilizada como um caminho para
permitir a comunicação entre dois pontos que se utilizam do Protocolo SOAP, onde
um ponto envia a mensagem e o outro a recebe (W3Cc, 2004).
Em SOUZA (2004) é encontrado um modelo gráfico do processo de
comunicação entre aplicações utilizando o protocolo SOAP, apresentado na Figura
18.
Figura 18: Modelo de Comunicação do Protocolo SOAP (SOUZA, 2004).
O Processo apresentado na Figura 18, encontrado em SOUZA (2004), ocorre
na seguinte seqüência de ações:
•
A envia solicitação a B para receber a Biblioteca de Tipos;
•
B envia resposta com a biblioteca de tipos;
•
A envia envelope com o método a ser chamado;
•
B executa o método e envia de volta o resultado;
25
O WSDL é um arquivo XML que descreve os métodos oferecidos pelo Web
Services servindo como uma Biblioteca com os tipos e funções dos métodos
oferecidos. Essa Biblioteca de Tipos será melhor apresentada na seção 2.7.3.
2.5.3 - WSDL
O SOAP define um padrão chamado WSDL, Web Services Description Language,
que descreve perfeitamente os objetos e métodos disponibilizados pelo Web
Services, através de páginas XML acessíveis através da Web (LINHADECODIGOa,
2004).
O WSDL é definido utilizando XML Schema (SOUZA, 2004) e é indispensável
para que possa existir a comunicação entre as aplicações, pois é necessário que
essas entendam o mecanismo de comunicação uma das outras. Esse mecanismo
descreve os métodos oferecidos, os tipos de retorno e parâmetros necessários.
Assim, o WSDL disponibiliza as informações necessárias para compor as
solicitações e as respostas SOAP.
O WSDL funciona como uma espécie de “biblioteca” do Web Services, além
de ser usado para a validação das chamadas dos métodos (PEREZ, 2004). Assim,
torna-se fácil para um usuário construir uma aplicação cliente que utilize as
funcionalidades oferecidas (LINHADECODIGOb, 2004).
O WSDL define uma gramática XML utilizada para descrever os serviços
oferecidos pelo Web Services através de uma coleção de pontos finais de
comunicação com capacidade de receber e executar mensagens de solicitação
(W3Cd, 2004).
2.6 – SVG (Scalable Vector Graphics)
Um objeto escalável, se tratando de gráficos, significa um objeto que não possui
tamanho fixo ou limitado para os pixels. Esse mesmo conceito na Web se aplica a
tecnologias que podem ter um grande número de usuários ou aplicações. SVG, por
ser uma tecnologia de Gráficos desenvolvida para Web, está ligada aos dois
significados do conceito de escalabilidade (W3Ca, 2004).
SVG é uma linguagem, baseada em XML, para a criação de imagens
bidimensionais onde a possibilidade de programação, controle, interação com o
26
usuário e conexão a banco de dados a tornam diferenciada de outros formatos como
JPEG e GIF (COELHO, 2004).
O padrão SVG ainda possui outras características apresentadas em
(EISENBERG, 2003) e (COELHO, 2004) que o diferencia dos demais formatos
encontrados atualmente:
•
a imagem pode ser redimensionada sem que se tenha perda da qualidade;
•
o formato texto facilita a criação e manipulação das imagens;
•
os conteúdos das imagens podem ser pesquisados através de ferramentas de
busca, localizando palavras-chaves contidas dentro das imagens;
•
uma imagem SVG pode ser acrescida de linguagens de script possibilitando
uma maior interação com o usuário. Essa integração com as linguagens de
script em SVG ocorre de forma semelhante ao HTML.
2.6.1. – Estrutura do Documento
Um documento SVG é um documento baseado no padrão XML, portanto é composto
por tags, que nada mais são do que metadados para os dados contidos no
documento. Na Figura 19 é apresentado um exemplo de um documento SVG, logo
em seguida, na Figura 20, é apresentada a imagem produzida por este documento.
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="5cm" height="4cm" version="1.1"
xmlns="http://www.w3.org/2000/svg">
<desc>Quatro Retângulos Separados</desc>
<rect x="0.5cm" y="0.5cm" width="2cm" height="1cm"/>
<rect x="0.5cm" y="2cm" width="1cm" height="1.5cm"/>
<rect x="3cm" y="0.5cm" width="1.5cm" height="2cm"/>
<rect x="3.5cm" y="3cm" width="1cm" height="0.5cm"/>
<rect x=".01cm" y=".01cm" width="4.98cm" height="3.98cm"
fill="none" stroke="blue" stroke-width=".02cm" />
</svg>
Figura 19: Exemplo de Documento SVG. (W3Ca, 2004).
27
Figura 20: Imagem da Exibição do Documento apresentado na Figura 19. (W3Ca,
2004)
O documento inicia com a indicação da versão do padrão XML utilizado, logo
em seguida, é indicada a DTD utilizada para definição da estrutura do documento
SVG. O início da imagem vetorial no SVG é estabelecido pela tag svg (COELHO,
2004), além disso, nessa tag são definidas a largura e altura da região do desenho
dos gráficos existentes no documento e o namespace utilizado pelo documento. Os
NameSpaces são nomes atribuídos a locais que possuem declarações de entidades
permitindo que suas funcionalidades possam ser reutilizadas por diferentes
aplicações.
Abaixo da tag svg encontra-se a descrição do desenho, tag desc, e ainda, a
descrição das geometrias existentes no documento. As geometrias resultantes
desse documento são quatro retângulos, cercados por outro retângulo utilizado para
definir a linha de contorno (última tag rect). A descrição das geometrias suportas
pelo padrão SVG serão apresentadas nas seções seguintes.
2.6.2. – Geometrias Básicas
As Geometrias básicas no SVG, utilizadas para a criação da maioria das imagens
vetoriais são: retângulo, linha, polígono, círculo e elipse (COELHO, 2004). Esses
elementos são representados pelas tags rect,
line,
polygon,
circle,
ellipse, respectivamente (W3Ca, 2004).
Na Figura 21 são apresentados exemplos da utilização das geometrias
básicas do SVG. Na Figura 22 são apresentados os gráficos produzidos por este
documento.
28
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="12cm" height="16cm" viewBox="0 0 1200 1600"
xmlns="http://www.w3.org/2000/svg" version="1.1">
<desc>Exemplo de Geometrias Básicas</desc>
<rect x="400" y="10" width="400" height="200" fill="yellow" stroke="navy" strokewidth="10"/>
<line x1="500" y1="280" x2="700" y2="480" stroke="navy" stroke-width="10" />
<polyline fill="none" stroke="navy" stroke-width="10"
points="400,675
450,675 450,625 550,625 550,675
650,675 650,580 750,580 750,675" />
<polygon fill="yellow" stroke="navy" stroke-width="10"
points="550,775 658,837.5 658,962.5
550,1030 442,962.5 442,837.5" />
<circle cx="550" cy="1200" r="100" fill="yellow" stroke="navy" stroke-width="10" />
<ellipse cx="550" cy="1450" rx="150" ry="80" fill="yellow" stroke="navy" strokewidth="10"/>
</svg>
Figura 21: Exemplo da utilização das geometrias básicas do SVG.
Figura 22: Geometrias geradas pela Figura 21.
29
2.6.2.1. – Retângulo
É definido utilizando o elemento rect. A utilização desse elemento irá criar um
retângulo dentro do espaço definido para criação dos gráficos, com altura e largura
de acordo com o repassado nos parâmetros width e height, alinhado de acordo com
as coordenadas definidas pelos valores passados para os parâmetros x e y
existentes dentro desse elemento. Pode ainda gerar retângulos com as bordas
arredondadas, através da definição de valores para os parâmetros rx e ry (W3Ca,
2004).
2.6.2.2. – Linha
É definida utilizando a tag line, indicando os pontos inicial e final para que se possa
traçar uma reta, os pontos são definidos através dos valores repassados para os
parâmetros x1 e y1 para ponto inicial, e, x2 e y2 para o ponto final (W3Ca, 2004).
Além dos pontos inicial e final na tag line também é definida a largura da reta,
utilizando o parâmetro stroke-width. Na Figura 28 é apresentado um exemplo de
documento SVG que utiliza o elemento line. A tag g iniciada antes das tags line,
indica o início de um grupo de geometrias que utilizarão um mesmo valor para uma
de suas propriedades, neste caso, o valor green para a propriedade stroke, definindo
a cor das linhas como verde.
Além de seguimentos de retas que podem ser desenhados através do
elemento line, o SVG suporta também múltiplos seguimentos de reta conectados,
que podem ser desenhados utilizando o elemento polyline. Neste elemento, ao
invés de se definir os pontos inicial e final para uma reta, é definido o conjunto de
pontos iniciais e finais que formam as retas, através dos valores repassados para o
parâmetro points.
2.6.2.3. – Polígono
É definido utilizando a tag polygon. Este elemento possui os mesmos parâmetros
existentes no polyline, apresentado anteriormente. A diferença entre eles é que
30
um polygon representa uma cadeia fechada de seguimentos de reta, enquanto que
o outro elemento representa uma cadeia aberta (W3Ca, 2004).
2.6.2.4. – Círculo
Essa geometria é definida utilizando a tag circle. Para tal devem ser passados os
valores para os parâmetros cx, cy e r, que definem o ponto central e o raio que serão
utilizados para composição do círculo (W3C, 2004).
2.6.2.5. – Elipse
É definido utilizando a tag ellipse. Esse elemento possui parâmetros semelhantes
ao elemento circle, diferenciando no tratamento do parâmetro raio, que no
elemento anterior utilizava apenas um valor e agora são atribuídos dois valores, rx e
ry. Assim como no elemento anterior, os parâmetros cx e cy, representam o ponto
central da geometria (W3Ca, 2004).
2.6.3. – Elemento Path
Um path é descrito usando o conceito de um ponto atual. Em uma analogia com
desenho feito no papel, o ponto atual pode ser interpretado como a posição da
caneta. A posição da caneta pode ser mudada e o desenho de uma forma (aberta
ou fechada) pode ser seguido arrastando a caneta em linhas retas ou curvas (W3Ca,
2004).
Para desenhar uma geometria, o elemento path utiliza os comandos moveto
(indica um novo ponto atual), lineto (desenha uma linha reta), curveto (desenha uma
curva usando um Bézier cúbico), arc (desenha um arco elíptico ou circular) e
closepath (parte do ponto atual e traça uma linha até o último moveto), que tem seus
valores definidos dentro do parâmetro d do elemento path.
A Tabela 1 apresenta a descrição dos parâmetros que devem ser repassados
para os comandos utilizados pelo elemento path.
31
Tabela 1 – Descrição dos Parâmetros dos Comandos do elemento path (W3Ca, 2004).
Nome
MoveTo
LineTo
ClosePath
Comando
Parâmetros
M ou m
(x y) +
L ou l
(x y) +
H ou h
x+
V ou v
y+
Z ou z
-
C ou c
(x1 y1 x2 y2 x y) +
S ou s
(x2 y2 x y)+
Q ou q
(x1 y1 x y)+
T ou t
(x y)+
Cubic Bézier
Quadratic Bézier
Descrição
Indica o ponto a partir do qual deverá iniciar o caminho
(desenho). Pode ser definido mais de um ponto, o que
indica a existência de sub-caminho, a partir do primeiro
ponto.
Indica o ponto final para o seguimento de reta que será
traçado a partir do ponto atual. Pode ser definido mais
de um ponto, o que irá resultar em um conjunto de
retas conectadas.
Indica o valor para coordenada x do ponto final para o
seguimento de reta que será traçado, tomando o valor
da coordenada y do ponto atual também como valor
para y do ponto final. Também pode ser definido mais
de um valor, resultando em um conjunto de retas.
Indica o valor para coordenada y do ponto final para o
seguimento de reta que será traçado, tomando o valor
da coordenada x do ponto atual também como valor
para x do ponto final. Também pode ser definido mais
de um valor, resultando em um conjunto de retas.
Indica o final de um caminho, ou desenho. Indica o final
do caminho definido pelo ponto inicial, ou um subcaminho definido a partir deste.
Indica o desenho de uma curva de Bézier Cúbica a
partir do ponto atual. Utiliza os valores de x1 e y1 como
pontos de controle da primeira curva e x2 e y2 para a
segunda curva. Os valores de x e y, finais, indicam o
novo ponto atual após o desenho da curva. Pode-se
ainda, definir um conjunto de curvas conectadas.
Indica o desenho de uma curva de Bézier Cúbica a
partir do ponto atual. Caso o comando anterior seja um
comando C, c, S ou s, o primeiro ponto de controle é
definido através da reflexão do segundo ponto de
controle do comando anterior. Caso contrário, o
primeiro ponto de controle é assumido como sendo o
próprio ponto atual. Os parâmetros x2 e y2 indicam o
segundo ponto de controle. Os parâmetros x e y
indicam o novo ponto atual após o desenho da curva.
Pode ser definido um conjunto de comandos S ou s.
Indica o desenho de uma curva de Bézier Quadrática
partindo do ponto atual e utilizando os valores de x1 e
y1 como ponto central da curva. Os valores de x e y
são para definir o novo ponto atual. Pode ser definido
um conjunto de curvas conectadas.
Indica o desenho de uma curva de Bézier Quadrática a
partir do ponto atual. Caso o comando anterior seja um
comando Q, q, T ou t, o ponto de controle é definido
através da reflexão do ponto de controle do comando
anterior. Caso contrário, o ponto de controle é
assumido como sendo o próprio ponto atual. Os
parâmetros x e y indicam o novo ponto atual após o
desenho da curva.
Pode ser definido um conjunto de comandos T ou t.
32
Elliptical arc
A ou a
(rx ry x-axisrotation largearc-flag sweepflag x y) +
Indica o desenho de um arco eliptico a partir do ponto
atual. O tamanho do arco é definido pelos parâmetros
rx e ry, que indicam os seus raios, e pelo parâmetro xaxis-rotation, que indica o valor da rotação do arco em
relação ao eixo x. Os pontos centrais da elipse são
calculados automaticamente utilizando os valores
repassados nos parâmetros large-arc-flag e sweep-flag,
que além disso, servem para determinar como o arco
será desenhado.
Os comandos do elemento path podem utilizar coordenadas absolutas
(comandos com letras maiúsculas) ou coordenadas relativas (comandos com letras
minúsculas). Os comandos com coordenadas absolutas utilizam como referência o
ponto (0,0) para definirem o local do ponto passado por parâmetro. Enquanto que os
comandos com coordenadas relativas utilizam o último ponto atual como referência
para identificar o local do ponto passado por parâmetro (ALTOQI, 2004).
Na Figura 23 é apresentado um documento com exemplos da utilização dos
comandos path apresentados na Tabela 1. Na Figura 24, são apresentados os
gráficos produzidos por este documento.
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="8cm" height="12cm" viewBox="0 0 800 1200"
xmlns="http://www.w3.org/2000/svg" version="1.1">
<desc>Exemplo de utilização do Elemento path</desc>
<path d="M 100 30 L 100 230 M 200 230 H 350 M 450 30 V 230 z" stroke="navy" strokewidth="10"/>
<path d="M 100,400 C 125,300 225,300 250,400 S 375,500 400,400" fill="none"
stroke="navy" stroke-width="10"/>
<path d="M 100,700 Q 200,550 300,700 T 500,700" fill="none" stroke="navy" strokewidth="10"/>
<path d="M 100,1100
a 25,25 -30 0,1 50,-25 l 50,-25
a 25,50 -30 0,1 50,-25 l 50,-25
a 25,75 -30 0,1 50,-25 l 50,-25
a 25,100 -30 0,1 50,-25 l 50,-25" fill="none" stroke="navy" strokewidth="10"/>
</svg>
Figura 23: Exemplo da utilização dos Comandos path.
33
Figura 24: Gráficos gerados pelo exemplo da Figura 23.
34
3 – Resultados e Discussões
3.1 – Considerações Iniciais
Neste Capítulo será apresentada a proposta de modelo de representação de dados
geográficos através da Web. Além da proposta, será apresentado um esquema
gráfico da Arquitetura do Modelo, para que se possa ter uma visão geral do modelo
de representação, bem como identificar os relacionamentos existentes entre as
partes, ou camadas, que compõem esse modelo.
Ainda nesse Capítulo as camadas definidas para o modelo serão detalhadas,
possibilitando uma maior compreensão do funcionamento interno da proposta e
auxiliando no processo de definição da melhor estratégia a ser utilizada na fase de
implementação.
3.2. – Apresentação do Modelo de Representação de Dados Geográficos
A motivação do presente trabalho é propor um modelo para que usuários possam
acessar e visualizar dados geográficos remotamente e também que este modelo de
representação de dados sirva de base para que usuários/desenvolvedores possam
aperfeiçoar, ou mesmo criar novas aplicações para os SGBD’s Geográficos.
Objetivando uma maior utilização desta proposta, o modelo apresentado,
devido às tecnologias utilizadas, tem condições de trabalhar de forma independente
da plataforma de desenvolvimento. A única exceção a este fato é a proposta de
utilização do ambiente SPRING como SGBD Geográfico, mas mesmo esse
ambiente pode ser substituído por outro, seguindo a arquitetura que será
apresentada nas próximas seções, obtendo resultado final semelhante.
Para possibilitar o acesso e consulta remota aos dados esse trabalho propõe
a utilização das tecnologias: SGBDG SPRING para permitir o armazenamento e
35
acesso aos dados, atuando no lado servidor; aplicação com tecnologia de Web
Services, para permitir a comunicação entre cliente/servidor; formato SVG para
representação dos dados geográficos resultantes das solicitações feitas pelo usuário
(cliente); aplicação cliente em ambiente Web, podendo ser acessada de qualquer
máquina onde se tenha acesso à Internet e um navegador web.
Nas próximas seções será apresentada a arquitetura definida para esta
proposta, além de um detalhamento das camadas componentes do modelo de
representação, permitindo uma maior compreensão sobre a proposta como um todo.
3.3 – Camadas do Modelo
Nesta seção serão apresentadas as camadas propostas para o modelo de
representação de dados geográficos através da Web, identificando sua importância
e funcionalidades, durante o processo de comunicação entre cliente/servidor e
acesso/representação dos dados.
A Figura 25 apresenta as camadas necessárias para o desenvolvimento do
modelo de representação e o fluxo de comunicação existente entre elas.
Figura 25: Camadas do Modelo de Representação.
36
3.3.1 – Aplicação Cliente
A camada de Aplicação Cliente é a responsável pela interação direta com o usuário.
Na prática, será uma aplicação desenvolvida para trabalhar em ambiente Web que
deve possibilitar ao usuário enviar solicitações de acesso e consulta aos dados
geográficos armazenados remotamente, através dos métodos disponibilizados pela
camada de Web Services, que será apresentada na próxima seção.
Além disso, essa camada realiza a conversão dos dados recebidos como
respostas das solicitações feitas pelo usuário, formato XML, para o formato SVG,
formato proposto para realizar a representação dos dados, possibilitando que os
resultados das solicitações sejam exibidos para o usuário.
Esta camada ainda pode ser acrescida de outras funcionalidades, como:
ferramenta de zoom durante a exibição dos dados; salvar o resultado das
solicitações; conversão do resultado para outros formatos; e assim por diante. Devese ressaltar, que o foco principal deste trabalho é propor um modelo de
representação, portanto, não serão abordados o projeto/desenvolvimento de outras
funcionalidades.
3.3.2 – Web Services
A camada de Web Services serve como ponte de ligação entre a camada de
Aplicação Cliente e a camada de SGBDG SPRING. Esta camada desenvolvida
utilizando a tecnologia de Web Services, apresentada em seções anteriores,
disponibiliza alguns métodos para que a camada de Aplicação Cliente tenha acesso
aos dados armazenados na camada de SGBDG SPRING. Além disso, tem papel
crucial para a independência de plataforma, devido a algumas características
próprias desta tecnologia.
Alguns dos métodos que devem ser disponibilizados pela camada de Web
Services para que o usuário possa realizar as tarefas propostas por esse modelo
são apresentados nas próximas seções.
37
3.3.3 – SGBDG SPRING
Esta camada é responsável pelo armazenamento e gerenciamento dos dados
geográficos. Além disso, nesta camada são executadas as solicitações repassadas
pela camada de Aplicação Cliente através dos métodos disponibilizados na camada
de Web Services.
Os resultados das execuções realizadas por esta camada são retornados
para a camada de Web Services que os encaminha para a camada de Aplicação
Cliente no formato XML.
Esta camada do modelo não tem a necessidade de ser implementada, por
utilizar o SGBDG SPRING para realizar suas funções.
Porém, para que esta proposta possa ser implementada é necessário que
ocorram algumas modificações na versão atual do SGBDG SPRING, versão 4.1,
para possibilitar o acesso aos dados a partir de aplicações externas ao SPRING. Na
versão atual ainda não existe nenhuma maneira de realizar esta operação de forma
direta.
3.4 – Arquitetura do Modelo
Na Figura 26 é apresentada a arquitetura definida para o modelo proposto neste
trabalho. Com a observação dessa Arquitetura pode-se ter uma maior compreensão
sobre o modelo de representação como um todo, identificando as entidades
envolvidas no processo de consulta/representação dos dados e dos relacionamentos
existentes entre essas entidades.
38
Figura 26: Arquitetura Definida para o Modelo Proposto.
As camadas existentes no Modelo são representadas na Arquitetura (Figura
26) por uma área de preenchimento cinza e identificadas por números dentro de
círculos, localizados no canto inferior direito de cada área. Cada número identifica
uma Camada distinta, conforme a seguinte descrição: 1 – Camada de Aplicação
Cliente; 2 – Camada de Web Services; 3 – Camada de SGBDG SPRING.
3.4.1 – Funcionamento da Arquitetura
Seguindo as setas indicativas existentes na Arquitetura, Figura 47, pode-se
identificar a seqüência de passos necessários para o funcionamento do Modelo,
desde a execução das solicitações efetuadas pelo usuário até a visualização do
resultado final:
•
Usuário acessa a Aplicação através do Navegador Web e faz uma solicitação
qualquer;
39
•
A aplicação Cliente, por sua vez, é a responsável por acessar os métodos
disponibilizados pelo Web Services;
•
Através dos métodos acessados pela aplicação Cliente o Web Services se
conecta e envia a solicitação ao SGBDG;
•
O SGBDG recebe e executa a solicitação repassada. Para realizar a tarefa de
execução o SGBDG acessa e consulta os dados que ele gerencia;
•
Após executar a solicitação o SPRING retorna o resultado (conjunto de
dados) para o método do Web Services que repassou a solicitação;
•
O método responsável pela solicitação retorna o resultado (conjunto de
dados) para a aplicação Cliente, em formato XML;
•
A aplicação Cliente ao receber o resultado da solicitação, converte os dados
para o formato SVG, permitindo que sejam visualizados pelo navegador Web;
•
Após a conversão dos dados o navegador Web exibe o resultado para que o
usuário possa visualizá-lo.
As subseções a seguir identificarão a funcionalidade de cada uma das
entidades representadas na Arquitetura definida para o Modelo desta proposta.
3.4.1.1 – Usuário
É a única entidade apresentada na Arquitetura que não está presente em nenhuma
das camadas do Modelo, por representar o próprio usuário que estará utilizando a
aplicação.
Esta entidade possui relacionamentos diretos com as entidades Navegador
Web e SVG, que serão apresentadas mais à frente. Esses relacionamentos
permitem que o usuário acesse e efetue solicitações para a Aplicação, além de
visualizar os resultados dessas solicitações que serão exibidos pelo navegador.
3.4.1.2 – Navegador Web
Esta entidade pertence à camada de Aplicação Cliente. Tem por objetivo principal
prover o ambiente de trabalho para a entidade Aplicação executar suas tarefas.
O Navegador Web é responsável por fazer a ponte de ligação entre o usuário
e a aplicação, no instante do repasse das solicitações do usuário. Além disso, após
40
a aplicação converter o resultado da solicitação para SVG, é o Navegador Web que
exibe esse resultado para o usuário poder visualizá-lo. Importante ressaltar que para
exibir esse resultado é necessário que seja instalado um Plug-in para SVG no
navegador.
3.4.1.3 – Aplicação
Esta entidade, a exemplo do Navegador Web, pertence a camada de Aplicação
Cliente, apresentada em seções anteriores. Na Arquitetura essa entidade aparece
dentro da entidade Navegador Web por necessitar do ambiente propiciado pelo
navegador para poder executar suas tarefas.
A entidade Aplicação tem como finalidade acessar e repassar para os
métodos existentes na camada de Web Services as solicitações efetuadas pelo
usuário. Além disso, essa entidade é responsável por receber os resultados dessas
solicitações em formato XML e convertê-los para o formato gráfico SVG.
3.4.1.4 – Métodos
Esta entidade, pertencente a camada de Web Services, representa os métodos
disponibilizados pela entidade Web Services. Esses métodos são os responsáveis
diretos por permitir que o usuário acesse e realize solicitações de consulta sobre os
dados gerenciados pela camada de SGBDG SPRING.
Algumas das funcionalidades que devem ser oferecidas pelos métodos que
serão disponibilizados para que o usuário tenha acesso às informações
armazenadas serão descritos nas próximas subseções. Porém, deve-se ressaltar
que estas funcionalidades se aplicam para acesso aos dados armazenados em
SGBDG SPRING, caso deseje-se seguir a Arquitetura apresentada na Figura 47
para acessar dados armazenados em outros SGBDG’s deve-se analisar a forma
como esses gerenciadores realizam o armazenamento e recuperação das
informações para definir as funcionalidades ou métodos que necessitam serem
implementados.
41
3.4.1.4.1 – Ativar/Desativar Banco de Dados
Responsável por ativar ou desativar um Banco de Dados existente no SGBDG
SPRING e deixá-lo em estado apto para receber as solicitações do usuário.
Importante lembrar que devido ao modelo de armazenamento adotado pelo SPRING
é necessário que o usuário possua permissão para acesso às tabelas que
armazenam os dados, caso deseje acessar um banco de dados do tipo Oracle.
Para a implementação dessas duas funcionalidades, são sugeridas as
seguintes assinaturas para os métodos a serem disponibilizados:
•
public int abrirBanco(String nomeBanco, String nomeGerenciador);
o A função desse método é criar uma conexão com o Banco de Dados,
tornado-o ativo e disponível para ser acessado. Recebe como
parâmetro o nome do Banco que deve receber a conexão e o nome do
gerenciador utilizado para criar o Banco, já que o SPRING trabalha
com tipos de gerenciadores diferentes. O método retorna o valor 1 (um)
no caso de abertura com sucesso e 0 (zero) no caso de ocorrência de
alguma falha durante o processo.
•
public int fecharBanco(String nomeBanco);
o A função desse método é encerrar uma conexão com o Banco de
Dados iniciada pelo método anterior. Recebe por parâmetro apenas o
nome do banco que possui uma conexão aberta. O retorno do método
tem valor 1 (um) em caso de fechamento com sucesso e 0 (zero) em
caso de ocorrência de alguma falha durante o processo.
3.4.1.4.2 – Ativar/Desativar Projeto
Responsável por Ativar e Desativar um Projeto existente para a Base de Dados
Ativa. O Projeto é o responsável por definir os limites geográficos da área que pode
ser acessada pelo usuário.
A seguir são apresentados exemplos de assinaturas que podem ser utilizadas
para a implementação dessas funcionalidades:
42
•
public int abrirProjeto(String nomeProjeto);
o É importante ressaltar que para que esse método seja executado o
Banco de Dados ao qual o Projeto passado por parâmetro se refere
deve estar ativo. A função desse método é abrir um Projeto para que
possa ser utilizado pelo usuário, recebendo por parâmetro o nome do
projeto. O método retorna o valor 1 (um) caso consiga abrir com
sucesso e 0 (zero) caso falha na abertura do Projeto.
•
public int fecharProjeto(String nomeProjeto);
o Esse método tem por objetivo fechar um Projeto ativo permitindo que o
usuário possa abrir outro Projeto definido para o mesmo Banco de
Dados. Recebe como parâmetro o nome do projeto a ser fechado. O
método retorna o valor 1 (um) no caso de fechar com sucesso e 0
(zero) caso ocorra alguma falha.
3.4.1.4.4 – Classes necessárias à transição dos dados
Devido às características do modelo de armazenamento do SPRING, para a
implementação das próximas funcionalidades é necessário que se construa classes
para poderem receber as informações relativas as Categorias e Planos de
Informações
pertencentes
ao
Projeto
ativo
e
repassar
Representações que o usuário deseja visualizar.
Essas Classes podem ser estruturadas da seguinte forma:
•
public class Categoria{
String nome;
String tipo;
Vector planoInformacao;
public void Categoria(String nome, String tipo){
this.nome = nome;
this.tipo = tipo;
}
ao
SGBDG
as
43
public Vector GetRepresentacao(String tipo){
//Colocar
condicionais
para
retornar
o
conjunto
de
Representações de acordo com o tipo de Categoria, as Representações possíveis
são definidas pelo SGBDG SPRING e podem ser encontradas em (SPRINGb, 2004);
}
}
•
public class PlanoInformacao{
String nome;
Vector representacao;
public void PlanoInformacao(String nome, Vector representacao){
this.nome = nome;
this.representacao = representacao;
}
}
A classe Categoria possui os atributos nome (armazena o nome da Categoria)
e tipo (armazena o tipo da Categoria) que são do tipo String e planoInformacao
(armazena um vetor com objetos PlanoInformacao) que é do tipo Vector.
Além desses atributos, essa classe ainda possui um Método Construtor que
define os valores para os atributos nome e tipo e um método GetRepresentacao que
será o responsável por gerar um vetor contendo as representações possíveis para
os Planos de Informações pertencentes a essa Categoria. Esse método receberá por
parâmetro o tipo da Categoria e já terá os conjuntos de Representações possíveis
pré-definidos dentro de sua estrutura.
A classe PlanoInformacao possui os atributos nome (armazena o nome do
Plano de Informação) que é do tipo String, e representacao (armazena um vetor com
o conjunto de Representações possíveis para o Plano de Informação) que é do tipo
Vector. Além desses atributos, essa classe ainda possui um Método Construtor que
define os valores para os atributos nome e representacao.
44
3.4.1.4.5 – Buscar Categorias e Planos de Informações
A função desse método é retornar para o usuário todas as Categorias existentes
para o Projeto Ativo e os Planos de Informações pertencentes a essas Categorias.
Para que o usuário possa posteriormente definir quais as Representações deseja
exibir para cada Plano de Informação.
Importante lembrar que no SPRING cada Projeto pode possuir várias
Categorias e dentro destas podem existir vários Planos de Informações os quais
podem possuir várias Representações de acordo com o Tipo da Categoria a qual
esse Plano de Informação pertence. Esse conjunto de informações serve para definir
os dados que devem ser exibidos para o usuário como resposta da solicitação.
Deve-se ressaltar também que tanto as Categorias, quanto os Planos de Informação
já devem ter sido definidos no SGBDG SPRING antes de serem utilizados pelo
usuário.
•
public Vector buscarCategoria();
o Esse método tem por objetivo retornar para o usuário todas as
Categorias definidas para o Projeto ativo, bem como os Planos de
Informações definidos para essas Categorias. Retorna um vetor de
objetos do tipo Categoria.
3.4.1.4.6 – Exibir Mapa
Esse método tem por finalidade enviar para o SGBDG as Representações dos
Planos de Informação existentes que o usuário deseja visualizar. Para ter acesso
aos Planos de Informação existentes deve ser utilizado o método citado na
subseção anterior. Deve-se atentar para o fato de que o usuário pode solicitar a
exibição de mais de uma Categoria ou Plano de Informação ao mesmo tempo,
portanto o método deve prever tal possibilidade.
•
public RecordSet exibirCategoria (Vector categoria);
o Esse método tem por objetivo enviar para o SGBDG SPRING as
Representações
que o usuário deseja visualizar. Recebe por
parâmetro um vetor de objetos do tipo Categoria, isso porque,
seguindo a forma de trabalho do SPRING, um usuário pode visualizar
Representações de mais de um Plano de Informação ou Categoria ao
45
mesmo tempo. Esse método retorna um conjunto de dados
(RecordSet) pertencentes ao Projeto que satisfazem as especificações
definidas nas Categorias passadas por parâmetro.
3.4.1.5 – Web Services
A entidade Web Services pertence à camada de Web Services definida no modelo e
tem por finalidade possibilitar que os métodos existentes na entidade Métodos sejam
disponibilizados através da Web para acesso do usuário, além de possibilitar que
esses métodos enviem solicitações à entidade SGBDG.
3.4.1.6 – SGBDG
A entidade de SGBDG pertence à Camada SGBDG SPRING do Modelo definido
para esta proposta. Tem por finalidade representar o Gerenciador utilizado para
controlar os dados armazenados, no caso específico desse trabalho, o SGBDG
SPRING.
Essa entidade é responsável por receber as solicitações efetuadas pelo
usuário, diretamente dos métodos disponibilizados pela Camada de Web Services e
executar as solicitações desejadas, realizando para isso o acesso e consulta aos
dados gerenciados por ela.
Após a execução das solicitações, essa entidade retorna os dados obtidos
para os métodos da Camada de Web Services na forma como eles se encontram
armazenados, ou seja, os dados não são convertidos para nenhum outro formato
especial antes de serem retornados para a Camada superior.
3.4.1.7 – Dados
Esta entidade pertence à camada de SGBDG SPRING do Modelo definido para esta
proposta e representa os dados geográficos que são gerenciados pelo SPRING e
podem ser acessados pelo usuário.
46
3.4.1.8 – Resultado Solicitação
Esta entidade pertence à Camada de Web Services do Modelo e tem por finalidade
representar todos os dados resultantes da execução das solicitações feitas pelo
usuário, após serem transformados para o formato XML pelo Web Services.
3.4.1.9 – SVG
A entidade SVG pertence à Camada de Aplicação Cliente e é o resultado do
processo de conversão dos dados retornados pela Camada Web Services para o
formato SVG, permitindo que esses resultados sejam exibidos pelo Navegador Web
e visualizados pelo usuário.
3.5 – Exemplo de utilização da proposta
Nesta seção será apresentado um exemplo do funcionamento da proposta através
da solicitação da exibição de um conjunto de Categorias existentes em um Projeto
por parte do usuário.
A exibição do mapa desejado pode ser obtida pelo usuário através da
seguinte seqüência de passos:
1. Solicita a abertura do Banco: int retBanco = abrirBanco(“nome_banco”);
2. Solicita a abertura do Projeto: int retProj = abrirProjeto(“nome_projeto”);
3. Solicita a exibição das Categorias e Planos de Informações existentes no
Projeto: Vector vetCategorias = buscarCategorias();
4. Após selecionar as informações que deseja visualizar o usuário deverá
solicitar a exibição dos dados: RecordSet dados = exibirCategoria(Vector
vetCategoriasSelecionadas);
5. A Aplicação Cliente converte o retorno do método exibirCategoria para o
formato SVG e o navegador exibe o resultado para o usuário.
Utilizando uma Base de Dados SPRING disponível em (SPRINGa, 2004), que
apresenta informações sobre a cidade de São Carlos-SP e seguindo a seqüência de
passos descrita acima pode-se chegar aos seguintes resultados:
47
1. int retBanco = abrirBanco(“Sao_Carlos”);
2. int retProj = abrirProjeto(“Canchim”);
3. Vector vetCategorias = buscarCategorias();
Inicialmente será solicitada a exibição da Categoria Limites, Plano de
Informação recorte e Representação Linhas.
4. RecordSet dados = exibirCategoria(vetCategoriasSelecionadas);
5. A Aplicação Cliente converte o conteúdo de dados para o formato SVG e
exibe esse conteúdo através do navegador;
O resultado da solicitação realizada no passo 4 pode ser observado através
da Figura 27.
Figura 27: Exibição do resultado da solicitação feita no passo 4.
48
Agora, além da exibição da solicitação anterior, será solicitada a exibição da
Categoria Mapa_Geologia, Plano de Informação geologia e Representação Classes.
6. RecordSet dados = exibirCategoria(vetCategoriasSelecionadas);
7. A Aplicação Cliente converte o conteúdo de dados para o formato SVG e
exibe esse conteúdo através do navegador;
O resultado da solicitação efetuada no passo 6 pode ser observado na Figura
28.
Figura 28: Exibição do resultado da solicitação feita no passo 5.
Além da exibição das Categorias solicitadas no passo 6, no passo 8 será
solicitada também a exibição da Categoria Classes_Solos, Plano de Informação
solos e Representação Classes.
49
8. RecordSet dados = exibirCategoria(vetCategoriasSelecionadas);
9. A Aplicação Cliente converte o conteúdo de dados para o formato SVG e
exibe esse conteúdo através do navegador;
Como resultado da solicitação realizada no passo 8 a Aplicação Cliente irá
gerar o mapa que pode ser observado na Figura 29.
Figura 29: Exibição do resultado da solicitação feita no passo 6.
3.6 – Considerações Finais
Este Capítulo apresentou a proposta do modelo de representação de dados
geográficos, através da descrição da proposta, das camadas necessárias para o
processo de acesso/representação dos dados e da Arquitetura definida para o
modelo visando dar base para o desenvolvimento da proposta apresentada neste
trabalho.
50
4 – Conclusão
O presente trabalho apresentou uma proposta para o modelo de representação de
dados geográficos. Essa proposta foi desenvolvida visando definir uma maneira
através da qual o usuário pudesse acessar e visualizar dados geográficos
armazenados remotamente através da Web.
Essa proposta não citou funcionalidades como criação ou exclusão de
Categorias e Planos de Informação, além de execução de instruções em LEGAL por
acreditar que para implementação de tais funcionalidades faz-se necessário uma
maior alteração na estrutura de funcionamento do SPRING. Antes da integração
dessas funções ao modelo é necessário que o SPRING se torne um ambiente multiusuário. Além de que essas funcionalidades modificariam o conceito do modelo
apresentado, passando de modelo de representação para modelo de representação
e manipulação de dados geográficos, visto que tais funções poderiam alterar os
dados armazenados.
Como trabalho futuro propõe-se a implementação dessa proposta para que
então possamos ter uma ferramenta capaz de disponibilizar através da Web os
dados geográficos armazenados em SPRING sem a necessidade da replicação de
parte de uma base de dados existente.
51
5 - Bibliografia
AltoQI Tecnologia e Informática. Informativo da Comunidade AltoQI. Disponível
em:http://www.altoqi.com.br/Suporte/default.html?html/Informativo/05_04_02.htm
&2?menussuporte/mesuporteprinc.htm&0, acessado em 11 de Outubro de 2004.
ALVES, D. S. Mapeamento do Uso da Terra em Rondônia utilizando ténicas de
segmentação e classificação de imagens LANDSAT-TM. Anais do VIII
Simpósio Brasileiro de Sensoriamento Remoto, Salvador, April de 1996.
BORGES, Karla Albuquerque Vasconcelos. Modelagem de Dados Geográficos em
Discussão. Prodabel – Empresa de Informática e Informação do Município de
Belo Horizonte, 1996.
CAMARA, Gilberto. Desenvolvimento de Sistemas de Informações Geográficas
no Brasil: Desafios e Oportunidades. Semana de Geoprocessamento do Rio
de Janeiro. Rio de Janeiro-RJ, Outubro de 1996.
COELHO, Alex. Sistema de Auxílio à Localização no CEULP/ULBRA Utilizando
Imagens Vetoriais Scalable Vector Graphics. Centro Universitário Luterano de
Palmas – CEULP/ULBRA. Palmas-TO, 2004.
COUCLELIS, H. People Manipulate Objects (but Cultivate Fields): Beyond the
Raster-Vector Debate in GIS. In: Proc. International Conference on GIS - From
Space to Territory: Theories and Methods of Spatial Reasoning. Springer Lecture
Notes on Computer Science, vol. 639, pp. 65-77, 1992.
DAVIS, Clodeveu. Objetos Espaciais em Banco de Dados Relacional. Prodabel –
Empresa de Informática e Informação do Município de Belo Horizonte, 2001.
EISENBERG, J. David. SVG Essentials. Producing Scalable Vector Graphics
with XML. Publish by O'
Reilly & Associates, 2003.
GOODCHILD, M. Geographical data modeling. Computers & Geosciences, 18(4):
401-408, 1992.
KALANI, Amit. ASP.NET 1.0 with C#. Namespace Reference. Wrox, 2002.
KIRK, C., XML – Black Book. São Paulo – SP- Brasil : Makron Books, 2000.
52
LINHADECODIGOa.
SOAP
e
Web
Services.
Disponível
em:
http://www.linhadecodigo.com.br/artigos.asp?id_ac=38&pag=1, acessado em 24
de Setembro de 2004.
LINHADECODIGOb. Web Services: Java e XML juntos pela interoperabilidade.
Disponível em: http://www.linhadecodigo.com.br/artigos.asp?id_ac=378&pag=1,
acessado em 24 de Setembro de 2004.
LUZ, Antonio da Jr. Indexação em SGBD’s Geográficos: Uma Análise das
Estruturas
Utilizadas.
Centro
Universitário
Luterano
de
Palmas
–
CEULP/ULBRA. Palmas-TO, Julho, 2004.
NCGIA, The Research Plan for the National Center for Geographical Information and
Analysis. International Journal of Geographical Information Systems,
3(2):117-36, 1989.
NING, Carlos Ho Shih. Manual do SpringWeb v. 3.0. INPE, São José dos CamposSP. 2000.
PEREZ, Rogério L. G. Visão Geral sobre Web Services. Disponível em:
http://www.imasters.com.br/artigo.php?cn=1680&cc=74, acessado em 24 de
Setembro de 2004.
QUEIROZ, Daniela Mascarenhas. Armazenamento de Documento XML no Oracle
9i. Centro Universitário Luterano de Palmas – CEULP/ULBRA. Palmas-TO, 2002.
REEVE,
D.E.
Apostila On-Line. University de Salford.
Disponível
em:
http://www.els.salford.ac.uk/geog/staff/nmt/fungis/hsd/hsd5.htm, acessado em 13
de Setembro de 2004.
RUMBAUGH, J. Modelagem e projeto baseados em objetos. Rio de Janeiro,
Editora Campus, 1994. 652p.
SILBERSCHATZ, Abranham; KORTH, Henry F. e SUDARSHAN, S. Sistema de
Banco de Dados. 3ª ed. – São Paulo: MAKRON Books, 1999.
SILVA, Rosângela. Banco de Dados Geográficos: Uma Análise das Arquiteturas
Dual (Spring) e Integrada (Oracle Spatial). Escola Politécnica da USP. 2002.
SOUZA, Jackson Gomes de. Web Services na plataforma .NET. III Encontro de
Estudantes de Informática do Tocantins. Palmas-TO. Outubro, 2003.
SPRINGa. Sistema de Processamento de Informações Georeferenciadas.
Disponível em: http://www.dpi.inpe.br/spring/, acesso em 28 de Setembro de
2004.
53
SPRINGb. Manual de Ajuda do SPRING, disponível no Software SPRING versão
4.1, 2004.
THOMÉ, Rogério. Interoperabilidade em geoprocessamento: conversão entre
modelos conceituais de sistemas de informação geográfica e comparação
com o sistema Open GIS. INPE – Instituto Nacional de Pesquisas Espaciais.
São José dos Campos-SP, 1998.
W3Ca. Scalable Vector Graphics (SVG) 1.1 Specification. Disponível em:
http://www.w3.org/TR/SVG11/, acesso em 06 de Outubro de 2004.
W3Cb. Web Services Architecture. Disponível em: http://www.w3.org/TR/ws-arch/,
acessado em 14 de Outubro de 2004.
W3Cc.
SOAP
Version
1.2
Part
0:
Primer.
Disponível
em:
http://www.w3.org/TR/soap12-part0/#L1149, acessado em 15 de Outubro de
2004.
W3Cd. Web Services Description Language (WSDL) 1.1. Disponível em:
http://www.w3.org/TR/wsdl, acessado em 16 de Outubro de 2004.
WORBOYS, M.F. GIS: A Computing Perspective. London, Taylor and Francis,
1995.