Modelo de TCC para o Curso de Cincia da Computao da UNIVALIsiaibib01.univali.br/pdf/Jeferson...
83
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO DEFINIÇÃO DOS PARÂMETROS DE VISUALIZAÇÃO DE CARTAS TEMÁTICAS ATRAVÉS DE SLD NO UMN MAPSERVER Área de Sistemas de Informação por Jeferson Koslowski Carlos Henrique Bughi, Bel. Orientador Rafael Medeiros Sperb, Dr. Co-orientador Itajaí (SC), dezembro de 2005
Transcript of Modelo de TCC para o Curso de Cincia da Computao da UNIVALIsiaibib01.univali.br/pdf/Jeferson...
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DEFINIÇÃO DOS PARÂMETROS DE VISUALIZAÇÃO DE CARTAS TEMÁTICAS ATRAVÉS DE SLD NO UMN MAPSERVER
Área de Sistemas de Informação
por
Jeferson Koslowski
Carlos Henrique Bughi, Bel. Orientador
Rafael Medeiros Sperb, Dr. Co-orientador
Itajaí (SC), dezembro de 2005
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
DEFINIÇÃO DOS PARÂMETROS DE VISUALIZAÇÃO DE CARTAS TEMÁTICAS ATRAVÉS DE SLD NO UMN MAPSERVER
Área de Sistemas de Informação
por
Jeferson Koslowski Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Carlos Henrique Bughi, Bel.
Itajaí (SC), dezembro de 2005
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................iv
LISTA DE FIGURAS ...............................................................................v
LISTA DE TABELAS..............................................................................vi RESUMO .................................................................................................vii ABSTRACT ............................................................................................viii 1 INTRODUÇÃO.....................................................................................1 1.1 PROBLEMATIZAÇÃO ..................................................................................... 3 1.1.1 Formulação do Problema................................................................................. 3 1.1.2 Solução Proposta............................................................................................... 4 1.2 OBJETIVOS ........................................................................................................ 4 1.2.1 Objetivo Geral ................................................................................................... 4 1.2.2 Objetivos Específicos ........................................................................................ 4 1.3 METODOLOGIA................................................................................................ 5 1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA .......................................................7 2.1 WEBMAPPING................................................................................................... 7 2.1.1 UMN Mapserver ............................................................................................... 9 2.2 PADRÕES .......................................................................................................... 14 2.2.1 Importância dos padrões................................................................................ 14 2.2.2 Normalização................................................................................................... 14 2.2.3 Padrões para serviços geoespaciais e posicionamento................................. 18 2.2.4 XML ................................................................................................................. 27 2.3 C ANSI................................................................................................................ 36 2.4 LINGUAGENS FORMAIS E COMPILADORES ........................................ 37 2.4.1 Compilador ...................................................................................................... 37 2.4.2 Flex & Bison .................................................................................................... 39
3 PROJETO............................................................................................42 3.1 DIAGRAMA DE SEQÜÊNCIA....................................................................... 42 3.2 DIAGRAMA DE ATIVIDADES...................................................................... 43 3.3 IMPLEMENTAÇÃO ........................................................................................ 45 3.4 RESULTADOS .................................................................................................. 46 3.4.1 Visão geral das aplicações desenvolvidas...................................................... 47 3.4.2 Biblioteca para o UMN Mapserver ............................................................... 48 3.4.3 Módulo de geração de SLD para o ESRI ArcGis ........................................ 49 3.4.4 Aplicação webmapping................................................................................... 51
4 CONCLUSÃO.....................................................................................54
ii
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................56
A ARTIGO CIENTÍFICO .....................................................................60
iii
LISTA DE ABREVIATURAS
ABNT Associação Brasileira de Normas Técnicas API Application Program Interface CAD Computer Aided Design CGI Common Gateway Interface COPANT Comissão Pan-americana de Normas Técnicas DBMS Database Management System DTD Document Type Definition G10 Laboratório de Computação Aplicada GIF Graphics Interchange Format GMC Grupo Mercado Comum GML Geography Markup Language GPL General Public License HTML Hyper Text Markup Language HTTP HyperText Transport Protocol IEC International Electrotechnical Comission IIS Internet Information Services INTN Instituto Nacional de Tecnología y Normalización IRAM Instituto Argentino de Normalización ISO International Organization for Standardization JPEG Joint Photographic Experts Group LCA Laboratório de Computação Aplicada MNDNR Minnesota Department of Natural Resources NASA National Aeronautics and Space Administration ODBC Open DataBase Connectivity OGC Open Geospatial Consortium PHP Hypertext Preprocessor PNG Portable Network Graphics SFS Simple Features Specification SGML Standard Generalized Markup Language SIG Sistemas de Informação Geográfica SLD Styled Layer Descriptor SQL Structured Query Language TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UMN University of Minnesota UNIT Instituto Uruguayo de Normas Técnicas UNIVALI Universidade do Vale do Itajaí URL Uniform Resource Locator W3C World Wide Web Consortium WFS Web Feature Service WMS Web Map Service XML Extensible Markup Language XSD XML Schema Definition
iv
LISTA DE FIGURAS
Figura 1. Funcionamento de um sistema webmapping ........................................................................9 Figura 2. Exemplo de arquivo mapfile ...............................................................................................13 Figura 3. Saída gerada pelo UMN Mapserver....................................................................................13 Figura 4. Níveis de normas ................................................................................................................16 Figura 5. Interação dos padrões OGC com as aplicações ..................................................................19 Figura 6. Interface WFS .....................................................................................................................21 Figura 7. Resultado de uma requisição SLD......................................................................................26 Figura 8. Exemplo de arquivo SLD ...................................................................................................26 Figura 9. Exemplo de tags em XML..................................................................................................28 Figura 10. Exemplo de DTD para validar o XML da Figura 9..........................................................31 Figura 11. Exemplo de XML Schema para o XML da Figura 9........................................................33 Figura 12. Continuação do XML Schema apresentado na Figura 11 ................................................34 Figura 13. Um compilador .................................................................................................................37 Figura 14. Interação do analisador léxico com o parser ....................................................................38 Figura 15. Posição de um analisador sintático num modelo de compilador ......................................39 Figura 16. Diagrama de Seqüência para o módulo ............................................................................42 Figura 17. Diagrama de Atividades para o módulo ...........................................................................44 Figura 18. Integração entre o ESRI ArcGis e o UMN Mapserver .....................................................47 Figura 19. Arquivo maplexer.l para a nova linguagem......................................................................48 Figura 20. Comparativo entre o mapfile antes da alteração no analisador léxico (à esquerda) e após
as mudanças (à direita) ...............................................................................................................49 Figura 21. Módulo de exportação desenvolvido para o ESRI ArcGis ...............................................50 Figura 22. Documento XML gerado pelo módulo.............................................................................51 Figura 23. Template construído para a aplicação webgis...................................................................52 Figura 24. Template utilizado para desenhar a legenda do mapa.......................................................53 Figura 25. Aplicação webmapping desenvolvida para teste da biblioteca.........................................53
v
LISTA DE TABELAS
Tabela 1. Parâmetros de configuração do UMN Mapserver ..............................................................11 Tabela 2. Troca de mensagens do diagrama de seqüência da Figura 16............................................43
vi
RESUMO
KOSLOWSKI, Jeferson. Definição dos parâmetros de visualização de cartas temáticas através de SLD no UMN Mapserver. Itajaí, 2005. 84 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2005. A criação de cartas temáticas encontra no desenvolvimento de geotecnologias um importante suporte para análises geoespacias que, geralmente, são feitas em Sistemas de Informação Geográfica (SIG), como ArcGis, Jump e Grass. Os SIGs são, até o momento, aplicações residentes que requerem configurações robustas, devido a complexidade das análises geoespaciais que realizam. No entanto, há uma crescente demanda associada à distribuição das informações contidas nas cartas temáticas. Demanda esta que vem orientando as novas geotecnologias para o compartilhamento e visualização de cartas via web, num conceito denominado de webgis ou webmapping. Associada a esta demanda é desejável que os sistemas para visualização via web possam, de alguma forma, compartilhar a configuração das cartas temáticas geradas em SIGs. Dentre os sistemas webmapping existentes, o UMN Mapserver aparece com grande destaque, sendo atualmente a ferramenta opensource mais utilizada para este fim. O UMN Mapserver foi originalmente desenvolvido na University of Minnesota (UMN), através do projeto ForNet financiado pela NASA (National Aeronautics and Space Administration). No Brasil, o Laboratório de Computação Aplicada (LCA – G10) da Univali, desenvolveu a interface de conexão entre o UMN Mapserver e o banco de dados Oracle Spatial, tornando-se membro ativo da comunidade UMN Mapserver. Em 2004, o laboratório passou a organizar, oficialmente, o consórcio no Brasil. Assim, o presente trabalho visou o desenvolvimento de uma biblioteca escrita em ANSI C para a leitura, pelo UMN Mapserver, do arquivo de configuração dos parâmetros de visualização escrito em XML. O arquivo de configuração em XML baseia-se no esquema SLD (Styled Layer Descriptor) especificado pelo Open Geospatial Consortium (OGC). Eventualmente, espera-se que scripts sejam escritos por usuários e desenvolvedores de SIGs residentes, de modo a gerar automaticamente o XML de configuração dos parâmetros de visualização de cartas temáticas, reduzindo o tempo necessário para a disponibilização de cartas temáticas na web. Palavras-chave: XML. SLD. UMN Mapserver.
vii
ABSTRACT
Thematical mapping has found in the development of geotechnologies an important support for geospatial analyses. This kind of analysis are usually done in geographic information systems - GIS like ArcGis, Jump or Grass. GIS are desktop applications that require robust configurations due to complex algorithms they use. Despite its success, there has been an increasing demand associated with data visualization. This demand has led new geotecnologies development towards data sharing and visualization through web, a technology which has been called webgis or webmapping. Besides these characteristics, this concept might benefit from sharing thematic maps configuration with desktop SIG’s. Amongst the existing webmapping systems, the UMN Mapserver appears with great prominence, being the most used opensource tool. The UMN Mapserver was developed in the University of Minnesota (UMN), through the ForNet project financed for NASA (National Aeronautics and Space Administration). In Brazil, the Laboratório de Computação Aplicada (LCA - G10) from Univali, developed the interface of connection between the UMN Mapserver and the data base Oracle Spatial, becoming an active member of community UMN Mapserver. In 2004 the laboratory started to organize, officially, the consortium in Brazil. Thus, the present work focus in the development of a module written in ANSI C that uses XML for configuring visualization attributes of thematic maps for the UMN Mapserver, which are known as mapfiles. To accomplish with this objective it is also necessary to use a XML based on SLD (Styled Layer Descriptor) standards of the Open Geospatial Consortium (OGC). Eventually this module will allow GIS users to develop their own scripts to export GIS configuration, reducing time to publish thematic maps in webgis applications. Keywords: XML. SLD. UMN Mapserver.
viii
1 INTRODUÇÃO
A partir dos anos 60, e conjuntamente aos avanços da ciência e engenharia da computação,
surgiram os sistemas orientados ao desenho gráfico (CADs) e a cartografia. A evolução destes
sistemas está associada, primeiramente, aos achados na área de sensoriamento remoto, a qual
determinou o surgimento do geoprocessamento e o crescente interesse no emprego de cartas
temáticas para estudos das mais diversas naturezas. Posteriormente, surgiu a necessidade de
associar estes sistemas ao potencial oriundo da evolução da teoria e tecnologias de banco de dados,
permitindo que dados de monitoramento viessem a compor mapas temáticos dinâmicos. Esta
evolução deu origem aos Sistemas de Informação Geográfica (SIG), através dos quais complexas
análises geoespaciais podem ser desenvolvidas a partir de consultas aos bancos de dados
(BURROUGH, 1986).
Os SIGs são, até o momento, aplicações residentes que requerem configurações robustas,
devido a complexidade das análises geoespaciais que realizam. No entanto, há uma crescente
demanda associada à distribuição das informações contidas nas cartas temáticas. Demanda esta que
vem orientando as novas geotecnologias para o compartilhamento e visualização de cartas via web,
num conceito denominado de webgis ou webmapping (ver Seção 2.1). Associada a esta demanda é
desejável que os sistemas para visualização via web possam, de alguma forma, compartilhar a
configuração das cartas temáticas geradas pelos SIGs residentes.
O UMN Mapserver1 é uma ferramenta opensource para a visualização de cartas temáticas
dinâmicas para a Internet, nos moldes acima descritos. Sua principal função consiste na
apresentação de dados geocodificados em cartas temáticas, via Internet. Além da visualização, o
emprego do UMN Mapserver permite a materialização do conceito de distribuição, acessibilidade,
democratização e integração da informação, uma necessidade premente quando se considera
volumes de dados geoespaciais. No entanto, apesar de grandes qualidades, o UMN Mapserver não
permite a leitura das configurações de cartas temáticas realizadas pelos SIGs residentes. O
1 O UMN Mapserver foi desenvolvido inicialmente através de uma parceria entre o Minnesota Department of Natural Resources (MNDNR), a University of Minnesota (UMN) e a National Aeronautics and Space Administration (NASA), e encontra-se descrito na Sub-seção 2.1.1 .
desenvolvimento de tal funcionalidade encontra potencial quando se considera o XML2 (Extensible
Markup Language).
O XML tem se mostrado de grande importância para aplicações web, pois uma de suas
principais características e vantagens é a interoperabilidade que proporciona por ser um padrão
flexível, aberto e independente de dispositivo. Além disso, as aplicações podem ser construídas e
atualizadas mais rapidamente, e ainda permitir múltiplas formas de visualização de dados
estruturados.
Segundo Pitts-Moultis e Kirk (2000), o XML é um subconjunto do SGML (Standard
Generalized Markup Language - padrão de marcação generalizada) e não uma aplicação deste
último, como é o HTML (Hyper Text Markup Language). Ele fornece uma ampla gama de recursos,
incluindo os seguintes:
• Uma linguagem extensível que fornece a capacidade de definir suas próprias marcas e
atributos. Esses elementos e suas marcas de início e fim juntamente com seus atributos o
ajudam a definir os elementos estruturais do documento;
• A capacidade de aninhar estruturas de documentos dentro das estruturas de outros
documentos; e
• A capacidade de verificar a validade de estruturas de documentos durante o
processamento.
O XML provê uma representação estruturada de dados que mostrou ser amplamente
implementável e fácil de ser desenvolvida. Uma característica importante é que uma vez tendo sido
recebido o dado pelo cliente, tal dado pode ser manipulado, editado e visualizado sem a necessidade
de reacionar o servidor. Dessa forma, os servidores têm menor sobrecarga, reduzindo a necessidade
de computação e reduzindo também a requisição de banda passante para as comunicações entre
cliente e servidor (FURTADO, 2000).
Dentre os benefícios do uso do XML para desenvolvedores e usuários têm-se:
2 A tecnologia XML encontra-se descrita na Seção 2.2.4 .
2
• Desenvolvimento de aplicações web mais flexíveis. Isso inclui integração de dados de
fontes completamente diferentes, de múltiplas aplicações; computação e manipulação
local dos dados; múltiplas formas de visualização e atualização granular do conteúdo;
• Distribuição dos dados via rede de forma mais comprimida e escalável; e
• Padrões abertos.
Considerando as perspectivas oferecidas pelo XML e o UMN Mapserver, o presente
trabalho propõe o desenvolvimento de uma biblioteca escrita em linguagem ANSI C, a mesma
utilizada para implementação do UMN Mapserver, que permita o uso de arquivos XML para a
definição das configurações de estilo e simbologia de um uma carta temática no UMN Mapserver.
O arquivo de configuração em XML segue o esquema SLD (Styled Layer Descriptor),
padrão especificado pelo Open Geospatial Consortium (OGC). Também foi desenvolvido um
módulo para o ESRI ArcGis que realiza a exportação das configurações de visualização de cartas
temáticas para XML. Eventualmente, espera-se que scripts sejam escritos por usuários e
desenvolvedores de outros SIGs residentes, de modo a gerar automaticamente o XML de
configuração dos parâmetros de visualização para o UMN Mapserver, reduzindo o tempo
necessário para a disponibilização de cartas temáticas na web.
1.1 Problematização
1.1.1 Formulação do Problema
Um dos principais problemas encontrados pelos desenvolvedores que utilizam a ferramenta
UMN Mapserver é a demora para a configuração do arquivo mapfile. Esse problema é agravado
pelo fato que poucos aplicativos SIG desktop são capazes de disponibilizar tal configuração para o
UMN Mapserver.
Além disso, o arquivo mapfile utilizado para a configuração das cartas temáticas no UMN
Mapserver utiliza um formato próprio de configuração, pouco didático e funcional.
3
1.1.2 Solução Proposta
Utilizar o SLD para a configuração dos estilos do mapa. Para isso fez-se necessário
desenvolver uma biblioteca para o UMN Mapserver ser capaz de ler tal documento XML contendo
a configuração.
Com isso, aplicações SIG residentes podem exportar as configurações de estilo do mapa
para um documento XML a fim de o UMN Mapserver ler este arquivo e gerar o mapa. Desta forma,
a complexidade do arquivo mapfile torna-se menor e o tempo para a configuração de estilos
também diminui.
1.2 Objetivos
1.2.1 Objetivo Geral
O objetivo do projeto foi desenvolver uma biblioteca para o UMN Mapserver que permita o
uso de arquivos escritos em XML para a definição das configurações de estilo e simbologia de uma
carta temática.
1.2.2 Objetivos Específicos
Os objetivos específicos do projeto foram:
• Pesquisar e analisar os padrões especificados pelo OGC relacionados às funcionalidades
presentes no UMN Mapserver para desenvolvimento do documento XML;
• Modelar e desenvolver em ANSI C a biblioteca de leitura dos arquivos de configuração
dos parâmetros de visualização de cartas temáticas utilizando documentos XML;
• Construir uma aplicação webmapping utilizando o UMN Mapserver para teste do
módulo; e
• Testar e validar a biblioteca de leitura dos arquivos de configuração de cartas temáticas.
4
1.3 Metodologia
A metodologia seguida para o desenvolvimento deste trabalho contemplou as seguintes
etapas:
• Levantamento bibliográfico: estudo dos conceitos relacionados a webmapping e dos
padrões e normas utilizados nesta área de conhecimento e sua importância. Além de
estudo das ferramentas Flex & Bison, UMN Mapserver e da tecnologia XML utilizadas
ao longo do desenvolvimento;
• Análise: criação do diagrama de seqüência da biblioteca a fim de demonstrar a
colaboração dinâmica entre os vários objetos e um diagrama de atividades apresentando
as ações e os resultados; e
• Implementação: desenvolvimento da biblioteca para o UMN Mapserver utilizando a
linguagem ANSI C.
1.4 Estrutura do Trabalho
Este documento está estruturado em quatro capítulos. O Capítulo 1 apresentada uma
introdução sobre este projeto, qual o problema que motivou a realização deste trabalho, os objetivos
gerais e específicos, além desta seção apresentando a estrutura do trabalho.
O Capítulo 2 apresenta a fundamentação teórica abordando a tecnologia webmapping; a
importância dos padrões e entidades de normalização do interesse deste projeto; relação dos padrões
para serviços geoespaciais e pesquisa sobre a linguagem de marcação XML; e estudo de linguagens
formais e compiladores e das ferramentas Flex & Bison.
O levantamento bibliográfico sobre webmapping apresenta o conceito, bem como quais os
benefícios que esta tecnologia traz. Também mostra de maneira simplificada o funcionamento do
webmapping e apressenta a ferramenta UMN Mapserver. Na pesquisa sobre a importância dos
padrões e entidades de normalização, são abordados quais os principais fatores que levam as
empresas a adoção de padrões e quais vantagens eles trazem. Além disso, apresenta algumas
entidades de normalização responsáveis pela padronização de serviços geoespacias e da web.
Na etapa de estudo sobre padrões para serviços geoespaciais são apresentados alguns
padrões propostos pelo OGC e o padrão SLD que foi aplicado na etapa de implementação deste
5
projeto. O estudo sobre a linguagem de marcação XML apresenta de forma sucinta o que é o XML
e qual a sua importância. Também apresenta os formalismos de esquema DTD e XML Schema
utilizados na validação de documentos XML. No tópico estudo de linguagens formais e
compiladores é abordado o funcionamento de um compilador, mais especificamente, a análise
léxica, sintática e semântica. Também são apresentadas as ferramentas Flex & Bison, que geram
respectivamente analisadores léxicos e sintáticos.
O Capítulo 3 apresenta o projeto, que engloba a modelagem da biblioteca, através dos
diagramas de seqüência e atividades e a implementação. A modelagem do sistema feita de acordo
com a UML (Unified Modeling Language), demonstra como a biblioteca desenvolvida interage
com o UMN Mapserver para a construção de um mapa, e quais módulos foram implementados para
possibilitar a leitura de documentos XML.
O projeto também contempla a etapa de validação, onde foi desenvolvida uma aplicação
webmapping utilizando o UMN Mapserver para testar a biblioteca desenvolvida e um módulo
escrito em Visual Basic for Applications para a criação do arquivo de configuração pelo software
ESRI ArcGis. A Seção 3.3 apresenta detalhes à respeito de mudanças feitas ao longo da
implementação deste projeto e quais medidas foram tomadas.
O Capítulo 4 contém as conclusões obtidas com o este projeto, trabalhos futuros que
poderão ser desenvolvidos além das dificuldades encontradas, principalmente durante a fase de
implementação.
O texto ainda inclui um apêndice contento um artigo científico para publicação em eventos e
um anexo com a especificação do esquema SLD.
6
2 FUNDAMENTAÇÃO TEÓRICA
A escolha e aplicação de um padrão e a implementação da biblioteca requer o conhecimento
de diversos conceitos e tecnologias. A Seção 2.1 apresenta a tecnologia webmapping bem como a
ferramenta UMN Mapserver que implementa este conceito. Já a Seção 2.2 procura ressaltar a
importância da utilização de padrões além de algumas entidades de normalização e os padrões para
serviços geoespaciais além do XML. A seção seguinte, 2.3, apresenta a linguagem de programação
ANSI C, utilizada na ferramenta UMN Mapserver e na biblioteca desenvolvida. Finalmente, a
Seção 2.4 mostra o conceito de linguagens formais e compiladores bem como demonstra as
ferramentas Flex & Bison utilizadas no desenvolvimento.
2.1 Webmapping
A Internet constitui um meio privilegiado para a disponibilização de grandes quantidades de
informação a um grande público. A tecnologia webmapping permite disponibilizar na web
informação geográfica e funções tipicamente associadas aos Sistemas de Informação Geográfica
(SIG), designadamente funções de navegação do tipo zooms (alterações na escala) e pans
(movimentação da imagem sem alterar a escala) e funções de pesquisa gráfica e alfanumérica
(FURTADO et al., 2004). Além da visualização, o emprego do webmapping permite a
materialização do conceito de distribuição, acessibilidade, democratização e integração da
informação, uma necessidade premente quando se considera volumes de dados espaciais.
Segundo Furtado et al. (2004), este tipo de tecnologia permite disponibilizar informação no
formato vetorial e raster na web aumentando a interatividade e reduzindo o tempo de download da
informação. Deste modo, o usuário pode manipular informações geográficas sem a necessidade de
adquirir licenças de software SIG para cada estação de trabalho, reduzindo custos, ou possuir
conhecimentos prévios em sistemas de informação geográfica para, por exemplo, localizar uma
determinada área em um determinado município ou estabelecer um buffer3. É possível aliar a
facilidade de uso de uma interface web à facilidade de interpretação da representação de dados
visuais (mapas, gráficos, relatórios formatados) em uma solução simples para publicação de dados
para o usuário final (KANEGAE, 2003). 3 Em sistemas webmapping, buffer é a operação de delimitação de uma área externa ou interna a um objeto geográfico, a partir de uma distância pré-estabelecida.
Existe uma gama de sistemas webmapping que permite apresentar dados geoespacias
conectando-se a praticamente qualquer DBMS (Database Management System), ao contrário das
aplicações SIG desktop, que são limitadas ao DBMS a qual estão aptas a conectar. Além disso, os
desenvolvedores podem usar padrões abertos, ao contrário do que acontece em aplicações SIG
desktop, em que estão restritos a um conjunto de ferramentas fornecidas por um determinado
produto.
Existem diversas aplicações para sistemas webmapping nas mais variadas áreas, desde
agricultura de precisão à sistemas de rotas rodoviárias e urbanas. Através da área de estudo, onde se
deseja aplicar o webmapping, são definidas as características que podem ser adicionadas ao sistema,
além das funções básicas de zoom e pan.
Segundo Kanegae (2003), de maneira simplificada, o funcionamento de um sistema
webmapping pode ser descrito da seguinte forma (ver Figura 1):
1. Navegador web: é o software de interface do usuário. Através do navegador (como o
Internet Explorer ou Firefox) o usuário acessa a aplicação webmapping hospedada em
um determinado servidor web;
2. Servidor web: é o software responsável por fornecer ao computador cliente, em tempo
real, os dados solicitados. Pode-se citar como exemplo o Apache e o Internet
Information Services (IIS);
3. O servidor web comunica-se com o sistema webmapping (como o UMN Mapserver) que
realiza a leitura dos arquivos de dados geográficos, efetua uma operação específica
(aproximar, afastar, deslocar) e converte o resultado da consulta em uma imagem de
saída (GIF - Graphics Interchange Format, PNG - Portable Network Graphics, JPEG -
Joint Photographic Experts Group). Alguns sistemas webmapping podem acessar bancos
de dados geográficos, como o Oracle Spatial ou o PostGIS, para a leitura de dados;
4. Alguns sistemas webmapping possibilitam efetuar uma customização mais aprimorada
da aplicação através de linguagens script como PHP (Hypertext Preprocessor), Python e
Java;
5. Os dados geográficos são armazenados no formato suportado pelo sistema webmapping
ou em bancos de dados geográficos se existir suporte; e
8
6. O banco de dados corporativo compreende as informações de interesse dos usuários e
deve estar estruturado de modo que seus dados possam ser relacionados aos dados
geográficos e, conseqüentemente, possibilitar o usuário a obter respostas coesas para
suas consultas.
Customização
WEBSERVER
MAPSERVER
Dados Geográficos
Banco de Dados Corporativo
2
1
3
Customização 4
5 6
Figura 1. Funcionamento de um sistema webmapping
Fonte: Adaptado de Kanegae (2003).
A seguir, será apresentada a ferramenta UMN Mapserver que possibilita a criação de
aplicações webmapping.
2.1.1 UMN Mapserver
O UMN Mapserver é uma ferramenta opensource que originalmente foi desenvolvida na
University of Minnesota (UMN), através do projeto ForNet financiado pela NASA (National
Aeronautics and Space Administration). No Brasil, o Laboratório de Computação Aplicada (LCA –
G10) localizado na Univali, desenvolveu a interface de conexão entre o UMN Mapserver e o banco
de dados Oracle Spatial, tornando-se membro ativo da comunidade UMN Mapserver. Em 2004, o
laboratório passou a organizar, oficialmente, o consórcio no Brasil.
O UMN Mapserver suporta dois modos de operação: CGI (Common Gateway Interface) e
MapScript. O modo CGI possibilita aos desenvolvedores rapidamente construir e depurar
aplicações web baseados em bancos de dados SIG usando arquivos de texto para a configuração,
chamados de mapfile, e templates de apresentação. Neste modo, o executável do UMN Mapserver é
chamado diretamente, e renderiza uma página HTML baseado em parâmetros passados, e arquivos
de configuração estáticos armazenados no servidor web. Usando o MapScript, o UMN Mapserver é
9
chamado por uma linguagem script server-side. O script analisa a consulta, renderiza a página final
e chama as funções do UMN Mapserver quando necessário. Dentre as interfaces script disponíveis,
a PHP MapScript é a mais documentada, e provavelmente mais usada. Além desta, outras
linguagens script como Perl, Python, Tk/Tcl e Java podem ser utilizadas para construir aplicações
customizadas (SHEKHAR et al., 2001).
Como mencionado acima, a interface CGI utiliza dois arquivos armazenados no servidor
web: o mapfile e o template de apresentação. O mapfile é um arquivo texto contendo informações
de configuração e definição de objetos. As informações de configuração incluem itens como o
caminho para os arquivos de dados, as unidades do mapa e projeção. O mapfile também define os
objetos gráficos (o mapa principal, mapa de referência, barra de escala e legenda), a aparência e
características de cada um desses objetos.
O template de apresentação é um arquivo HTML que utiliza tags a serem substituídas por
parâmetros, que são designadas por colchetes: []. O arquivo template é a página HTML que os
usuários irão acessar em seus browsers depois que o UMN Mapserver substituir as tags com os seus
valores apropriados. Uma linha do arquivo template como:
<P> Escala do Mapa 1:[scale] </P>
deve resultar no browser do usuário: Escala do Mapa 1:1200.123456.
Este é um exemplo simples, entretanto, em muitos casos o Mapserver precisa executar um
processamento considerável para cada parâmetro a ser substituído, como no caso de renderizar uma
imagem. Neste caso o Mapserver cria uma imagem raster do mapa requerido. A imagem é
associada a um nome aleatório e salva em disco no servidor web. O parâmetro inserido no template
de visualização é o caminho para a imagem e o seu nome. Por exemplo, a seguinte linha no arquivo
de template:
<IMG src='[img]'>
irá fazer com que o Mapserver renderize o mapa e substitua o conteúdo entre colchetes por:
<IMG src= '/tmp/tc1 026152105592.png' >
O Mapserver lê o arquivo template e cria os objetos do mapa para a página HTML quando
encontra os colchetes. Os dados para os objetos do mapa e seu estilo são definidos no mapfile.
10
Para que o Mapserver saiba quais partes do mapa deseja-se desenhar, ou quais layers
apresentar, são passados parâmetros via URL na forma parâmetro=valor, sendo os elementos
separados por um &. Por exemplo, a seguinte URL:
http://localhost/cgi-bin/mapserv?map=mapfile.map&mode=map&layers=brasil
irá informar os seguintes dados como mostra a Tabela 1.
Tabela 1. Parâmetros de configuração do UMN Mapserver
Parâmetro Função http://localhost O endereço do servidor /cgi-bin/mapserv O programa executável do UMN Mapserver ? Indica o início dos parâmetros & Caractere que indica o início de um novo
parâmetro map=mapfile.map Define qual mapfile será utilizado mode=map Indica o modo de operação do UMN
Mapserver layers=brasil Quais layers serão desenhados
Com relação às especificações do OGC, o UMN Mapserver trabalha com SFS (através do
PostGIS), WFS (somente leitura), WMS e GML. Segundo o site oficial, já está em desenvolvimento
o padrão WCS (UCHOA e FERREIRA, 2004). Estes padrões serão abordados em maiores detalhes
na Sub-seção 2.2.3 .
A seguir será abordado em maiores detalhes o arquivo mapfile, que é um dos focos do
trabalho.
2.1.1.1 Mapfile
Segundo Doyon e Mckenna (2004), mapfile é o mecanismo de configuração básica para o
UMN Mapserver. Todas as configurações associadas à forma de apresentação do mapa são
definidas no mapfile, ainda que algumas opções possam ser alteradas via formulários web (variáveis
CGI). Os mapfiles são usados para controlar aspectos visuais da aplicação, como por exemplo,
quais camadas (layers) serão desenhadas, como serão renderizadas e consultadas (SHEKHAR et al.,
2001).
O mapfile é um arquivo de texto simples com a extensão “.map”. Os principais elementos
(objetos) de um arquivo map são:
11
• Map: indica o início do mapfile. É o elemento mestre, ou seja, contém todos os outros
elementos (elemento raiz). Ele define os parâmetros gerais da aplicação/mapa;
• Label: este elemento é utilizado para definir o rótulo usado para descrever uma
característica com um fragmento de texto. Labels também podem ser usados em
símbolos através do uso de fontes TrueType;
• Layer: o elemento mais usado em um mapfile, ele descreve as camadas de um mapa. Os
layers são desenhados na ordem em que aparecem no mapfile (o primeiro embaixo, o
último em cima);
• Class: define uma classe temática para um determinado layer (cada layer deve possuir
no mínimo uma classe);
• Style: este elemento contém parâmetros para simbolização. Múltiplos estilos podem ser
aplicados à uma classe;
• Legend: define como a legenda deve ser construída. A legenda é gerada
automaticamente utilizando o nome e os símbolos das classes de cada layer; e
• Scalebar: define como a barra de escala deve ser construída.
Cada elemento possui os seus respectivos atributos e outros elementos. Na Figura 2 é
apresentado um exemplo de mapfile (nele, os principais elementos encontram-se destacados em
negrito).
# ===== OBJETO MAP ===== map extent -54 -4 -48 0 units dd imagetype png size 400 400 imagecolor 240 240 240 shapepath "data" # ===== OBJETO LAYER ===== layer status default type polygon name "limite_politico" data "LIMITE_POLITICO_ADMINISTRATIVO" # ===== OBJETO CLASS ===== class name "Limite Político Administrativo" color 100 180 255 outlinecolor 0 0 0 end end # ===== OBJETO SCALEBAR ===== scalebar color 0 0 0
12
backgroundcolor 255 255 255 outlinecolor 0 0 0 position lc status embed units kilometers intervals 4 # ===== OBJETO LABEL ===== label color 0 0 0 end end # ===== OBJETO LEGEND ===== legend outlinecolor 0 0 0 position ul status embed # ===== OBJETO LABEL ===== label color 0 0 0 end end end
Figura 2. Exemplo de arquivo mapfile
Realizando uma chamada ao módulo CGI do UMN Mapserver através de um navegador
web, utilizando o mapfile da Figura 2, obtém-se a seguinte saída apresentada na Figura 3.
Figura 3. Saída gerada pelo UMN Mapserver
Pode-se observar que os sistemas webmapping buscam seguir padrões que garantam a
interoperabilidade entre os diversos aplicativos existentes. A seção a seguir aborda este assunto,
demonstrando para que servem e porque são considerados de extrema importância.
13
2.2 Padrões
Padronização é o trabalho para alcançar soluções comuns, sendo elaborado em cooperação
entre representantes de indústrias, usuários, comerciantes, consumidores, entre outros. O propósito
da padronização é criar uma plataforma comum para trabalhar, onde, por exemplo, todos conheçam
o significado de diferentes conceitos, tenham um procedimento uniforme ou tenham um mínimo de
requisitos definidos. O esforço pela padronização é geralmente conduzido em comitês técnicos,
grupos de trabalho ou projetos onde os participantes provêm de companhias, organizações ou
autoridades interessadas (HELLSTRÖM, 2005).
2.2.1 Importância dos padrões
Segundo Hellström (2005), a padronização hoje em dia é uma questão internacional.
Especialistas estão participando ativamente em padronizações internacionais com o intuito de
passar o ponto de vista de suas organizações e criar padrões técnicos que irão dar suporte ao
desenvolvimento da comunicação no futuro. Além do caso específico da comunicação, os padrões
podem estabelecer o tamanho ou forma de um determinado produto, processo ou sistema. Também
podem especificar a performance de produtos ou pessoal. Além disso, podem definir termos de
forma que não ocorram mal-entendidos entre aqueles que utilizem o padrão (ANSI, 2005).
Padrões oferecem uma enorme contribuição em vários aspectos, embora na maioria das
vezes esta contribuição não seja percebida. Quando eles não estão presentes é que se percebe sua
importância. Por exemplo, compradores ou usuários de produtos logo notam quando eles não
funcionam por má qualidade, são incompatíveis com os produtos já existentes, são inadequados ou
perigosos. Quando os produtos estão de acordo com as expectativas, tende-se a tê-los como
garantidos. Geralmente os compradores não têm consciência do papel dos padrões no aumento dos
níveis de qualidade, segurança, confiabilidade, eficiência e permutabilidade, assim como prover tais
benefícios a um custo econômico (ISO, 2005).
2.2.2 Normalização
A normalização estabelece, em relação a problemas existentes ou potenciais, prescrições
destinadas à utilização comum e repetitiva com vistas à obtenção do grau ótimo de ordem em um
dado contexto (ABNT, 2000). Ou seja, ela é uma maneira de organizar atividades pela criação e
utilização de regras e normas, elaboração, publicação e promoção do emprego destas normas e
14
regras, visando contribuir para o desenvolvimento econômico e social de uma nação. Isto é,
estabelece soluções para problemas (SEBRAE, 2004).
2.2.2.1 Classificação das normas
As normas podem ser classificadas de diversas maneiras, dependendo do enfoque desejado.
As duas principais classificações, sob as quais se encontram as normas são: quanto ao tipo e quanto
ao nível (SEBRAE, 2004).
Classificação quanto ao tipo
Segundo Sebrae (2004), existem sete tipos de normas:
1. De procedimento: define os procedimentos a serem seguidos no desenvolvimento de uma tarefa ou produto;
2. De especificação: define as características de uma tarefa ou produto;
3. De padronização: estabelece padrões de modo a restringir a variedade com o objetivo de
uniformizar as características, sejam elas de procedimentos ou dos produtos;
4. De ensaio: como testar procedimentos e produtos de maneira a verificar as
características, condições ou requisitos exigidos na especificação e padronização;
5. De classificação: define como classificar um conceito, material ou objeto de acordo com
uma determinada sistemática;
6. De terminologia: tem por objetivo o estabelecimento de uma linguagem uniforme para
definir termos e expressões associadas a um dado campo de conhecimento; e
7. De simbologia: propõe-se a fixar símbolos (convenções gráficas) para conceituar
grandezas, sistemas ou partes de sistemas.
Classificação quanto ao nível
Segundo Sebrae (2004), as normas podem ser classificadas em quatros níveis distintos,
conforme sua abrangência, como apresentado na Figura 4.
15
Figura 4. Níveis de normas
Fonte: (SEBRAE, 2004).
2.2.2.2 Objetivos da normalização
A normalização, dependendo do produto, processo ou serviço, pode ter um ou mais
objetivos específicos, quais sejam (SEBRAE, 2004):
• Simplificação: limitação da variedade dos produtos manufaturados e seus componentes.
Dessa forma o fabricante pode produzir um grande lote de produtos, similares em todas
as características, permitindo que elas possam substituir umas às outras sem alteração no
seu desempenho;
• Segurança: a segurança é um dos principais objetivos da normalização, precedendo em
importância a qualquer outro. Os produtos devem ser fabricados para que alcancem um
alto grau de confiabilidade, programados para serem testados, periodicamente, durante
sua vida útil;
• Proteção ao consumidor: adquirindo um produto normalizado, subentende-se que o
produto foi fabricado de acordo com os requisitos da norma pertinente, garantido-se
desta maneira, que o fabricante utilizou na sua fabricação, matéria-prima e processo
controlados e, principalmente, que o produto está de acordo com seu desejo e
necessidade;
• Eliminação das barreiras comerciais: visa alcançar concordância sobre o conteúdo
técnico das normas entre os especialistas internacionais, tais como acontece nos comitês
16
técnicos da ISO (International Organization for Standardization) e IEC (International
Electrotechnical Comission);
• Comunicação: a função básica das normas é prover meios de comunicação entre o
fabricante e o cliente. Onde a qualidade é especificada, a comunicação é um objetivo da
maior importância, pois os requisitos especificados devem ser expressos, de forma
facilmente compreendida pelas partes envolvidas; e
• Economia: com a sistematização e ordenação das atividades produtivas é evidenciada a
redução de custos de produtos e serviços, com a conseqüente economia para clientes e
fornecedores.
2.2.2.3 Entidades de normalização de interesse deste estudo
Como apresentado anteriormente (Figura 4), existem normas em nível internacional,
regional, nacional e empresarial. Para os níveis internacional, regional e nacional, existem órgãos
responsáveis pelos padrões. A seguir, serão apresentados os mais importantes para este trabalho.
17
ISO (International Organization for Standardization)
A ISO é uma organização não governamental, oficialmente fundada em 23 de fevereiro de
1947. É uma rede composta pelos institutos nacionais de padronização de 151 países, com a
secretaria central localizada em Genebra, Suíça, que coordena o sistema. A ISO está disposta a atuar
como uma organização ponte na qual um consenso pode ser alcançado em soluções que alcancem
os requisitos de negócio e as necessidades da sociedade (ISO, 2005).
W3C (World Wide Web Consortium)
O World Wide Web Consortium, ou W3C, é um consórcio internacional onde organizações,
funcionários e o público trabalham em conjunto para desenvolver padrões web. Sendo fundado em
1994, o W3C tem como missão conduzir a World Wide Web para o seu completo potencial através
do desenvolvimento de protocolos e pautas que garantam o crescimento da web (JACOBS, 2005).
OGC (Open Geospatial Consortium)
O Open Geospatial Consortium (OGC4) é uma organização internacional não lucrativa,
criada em 1994. O consórcio conta com mais de 250 companhias, agências governamentais e
universidades, e tem como objetivo o desenvolvimento de tecnologias que facilitem a
interoperabilidade entre sistemas envolvendo informação geoespacial e localização. Os produtos do
trabalho do OGC são apresentados sob forma de especificações de interfaces e padrões de
intercâmbio de dados (OGC, 2005).
2.2.3 Padrões para serviços geoespaciais e posicionamento
Segundo OGC (2005), muitos dados geoespaciais estão disponíveis na web e em
repositórios, contudo a maioria destes está armazenada em diferentes formatos, usando modelos de
dados diferentes, sistemas de coordenadas, modelos de geometria, etc. Sendo assim, compartilhar
dados geoespaciais tem requerido tempo, perícia e software especializados na integração. As
especificações OGC são desenvolvidas para permitir que os usuários maximizem os valores de
investimentos passados e futuros em sistemas de geoprocessamento e dados, atendendo a três
princípios básicos:
4 Inicialmente denominado Open GIS. Hoje o termo Open GIS é uma marca registrada utilizada para referenciar as diversas especificações do consórcio.
18
1. Compartilhamento e reuso de dados a fim de diminuir custos (evitar coleções de dados
redundantes) e conseguir mais ou melhor informação;
2. Escolha da melhor ferramenta para o trabalho e redução dos riscos de obtenção de
tecnologia; e
3. Maior número de pessoas com menor gasto em treinamento usando dados geoespaciais
em mais aplicações.
Estes princípios encontram-se associados à necessidade das organizações acessarem
informações geoespaciais uma das outras, sem a cópia e/ou conversão de todo o conjunto de dados;
das soluções trabalharem em conjunto; e das soluções em geoprocessamento se basearem na
arquitetura aberta World Wide Web.
O consórcio OGC define uma série de padrões computacionais que objetivam promover
interoperabilidade entre sistemas de informações geográficas. A Figura 5 apresenta como os
diversos padrões especificados pelo OGC, que estão descritos na seção a seguir, interagem com as
aplicações.
WFS WMS
Aplicações
Aplicações
SGBD
SFS
Aplicação A (ajuste de traçado de rios) Aplicação D
(análise visual de imagens)
Aplicação C(tributação)
Aplicação B (logística)
Aplicação E(sem conexão externa)
GML
SLD (documento SLD
definido pelo usuário)
Figura 5. Interação dos padrões OGC com as aplicações
Fonte: Adaptado de Uchoa e Ferreira (2004).
19
2.2.3.1 SFS (Simple Features Specification)
Esta especificação define um formato de acordo com o SQL (Structured Query Language)
para armazenamento, leitura, análise e atualização de dados geográficos através de uma API5
ODBC6 (UCHOA e FERREIRA, 2004).
2.2.3.2 WMS (Web Map Service)
O serviço WMS permite a publicação de mapas na web, produzidos a partir de dados
georeferenciados. Ele padroniza interfaces que devem ser utilizadas por clientes para requisitar
mapas aos servidores, e também padroniza o modo como estes servidores devem descrever e
retornar estes mapas (SILVA e PEREIRA, 2004). Para esta comunicação são definidas três
operações: GetCapabilities, GetMap e GetFeatureInfo.
1. GetCapabilities: permite ao cliente solicitar todas as metainformações sobre a base de
dados, tais como o nome dos mapas contidos, projeção, escala, estilos possíveis dos
mapas, formatos possíveis dos mapas (GIF, JPEG, PNG), formato das informações
descritivas (FeatureInfo). Os parâmetros da operação são recebidos via HTTP
(HyperText Transport Protocol) e a resposta deve ser um arquivo XML no mesmo
protocolo;
2. GetMap: retorna o mapa propriamente dito. Através desta operação, o cliente do Web
Service pode requisitar um mapa em particular. Para isto ele deve usar as informações
que foram retornadas pelo GetCapabilities. Os parâmetros da operação são recebidos via
HTTP e a resposta deve ser um arquivo de imagem no formato solicitado, que pode ser
um das opções: GIF, PNG ou JPEG; e
3. GetFeatureInfo: permite ao cliente realizar consultas nos mapas da base de dados. Os
parâmetros da operação são recebidos via HTTP e a resposta deve ser um arquivo no
formato solicitado que pode ser um dos seguintes: texto, XML ou GML. Esta operação
não é obrigatória, segundo o protocolo.
5 Application Program Interface é um conjunto de rotinas, protocolos e ferramentas para a construção de softwares aplicativos. 6 Open DataBase Connectivity é um método padrão de acesso a bancos de dados desenvolvido pelo grupo SQL Access em 1992. O objetivo do ODBC é tornar possível o acesso à qualquer dado através de qualquer aplicação, desconsiderando qual Database Management System (DBMS) está manipulando os dados.
20
2.2.3.3 WFS (Web Feature Service)
A especificação WFS define um serviço para que clientes possam requisitar à diversos
servidores WFS objetos (features) espaciais codificados em formato GML e atualizar estes dados.
Este serviço pode ser implementado pelo servidor em duas versões: básica, onde apenas
operações de consulta ficam disponíveis, ou transacional, que implementa o serviço completo, que
inclui operações de inserção, exclusão, atualização e consulta de objetos (features) geográficos
(DAVIS JÚNIOR et al., 2005). A interface WFS é ilustrada na Figura 6.
Figura 6. Interface WFS
Fonte: (VRETANOS, 2005).
Para este serviço são definidas as seguintes operações:
1. getCapabilities: descreve as características do servidor;
2. describeFeatureType: descreve a estrutura dos tipos de objeto que podem ser servidos;
3. getFeature: retorna instâncias dos objetos disponíveis na base de dados. O cliente pode
selecionar quais objetos deseja por critérios espaciais ou não;
4. transaction: utilizado para a execução de operações de modificação dos objetos
(inserção, exclusão e atualização); e
5. lockFeature: bloqueia uma ou mais instâncias durante uma transação.
21
2.2.3.4 WCS (Web Coverage Service)
Esta especificação foi criada para o acesso a dados que representam fenômenos com
variação contínua no espaço. O serviço é específico para o tratamento de dados modelados como
geo-campos, em complementação ao serviço WFS, que trata de dados modelados como geo-
objetos, isto é, que representam entidades espaciais discretas e bem definidas.
O serviço não retorna imagens das coverages como resposta das requisições, mas sim dados
sobre a semântica dos fenômenos representados.
Neste serviço são implementadas três operações:
1. getCapabilities: fornece uma descrição do servidor e informações básicas acerca das
coleções de dados disponíveis;
2. describeCoverage: recupera uma descrição completa das coverages; e
3. getCoverage: recupera uma coverage (valores e propriedades de um conjunto de
localizações geográficas) no servidor.
2.2.3.5 GML (Geography Markup Language)
O GML é um esquema utilizando o formalismo XML Schema para modelagem, transporte e
armazenamento de informações geográficas, incluindo aspectos geométricos e propriedades de
objetos de interesse. Atualmente, GML é uma recomendação proposta pelo consórcio Open
Geospatial e está aberta para discussões públicas (COX et al., 2004).
O GML provê uma variedade de tipos de objetos para descrever a geografia, incluindo
características, sistemas de coordenadas, geometria, topologia, tempo, unidades de medida e valores
em geral (ibidem).
Segundo Cox et al. (2004), esta especificação define mecanismos e convenções que:
• Fornecem uma estrutura aberta para a definição de esquemas de aplicações geoespaciais
e objetos;
• Permitem criar perfis que suportam subconjuntos apropriados das potencialidades
descritivas da estrutura GML;
22
• Suportam a descrição de esquemas de aplicações geoespaciais para domínios
especializados e comunidades de informação;
• Permitem a criação e manutenção de esquemas de aplicações geográficas e conjuntos de
dados;
• Suportam o armazenamento e transporte dos esquemas de aplicações e conjuntos de
dados; e
• Aumentam a capacidade das organizações compartilharem esquemas de aplicações
geográficas e a informação que descrevem.
Os desenvolvedores podem decidir armazenar esquemas de aplicações geográficas e
informações em GML, ou eles podem converter para outro formato de armazenamento e usar GML
somente para o esquema e transporte de dados (COX et al., 2004).
De acordo com Lima Júnior e Câmara (2002), o objetivo é oferecer um conjunto de regras
com as quais um usuário pode definir sua própria linguagem para descrever seus dados. O XML
Schema define os elementos (tags) usados em um documento que descreve os dados.
O GML inclui esquemas que contêm os modelos de geometria, feições (features) e
superfícies. Os principais são os seguintes (DAVIS JÚNIOR et al., 2005):
• BasicTypes: engloba uma série de componentes simples e genéricos para representação
arbitraria de atributos, nulos ou não;
• Topology: especifica as definições do esquema geométrico dos dados, bem como sua
descrição;
• CoordinateReference Systems: para sistemas de referência de coordenadas;
• Temporal Information and Dynamic Feature: este esquema estende aos elementos
características temporais dos dados geográficos e suas funções dinamicamente definidas;
• Definitions and Dictionaries: definições das condições de uso dentro de documentos
com certas propriedades ou informações de referentes à propriedade padrão; e
• Metadata: é utilizado para definir as propriedades dos pacotes de dados que podem ser
utilizados através de outros dados já existentes.
23
Dessa forma um usuário pode definir o seu próprio esquema para sua aplicação. Mas há
algumas exigências a seguir para obter conformidade (ibidem):
• Desenvolvedores de esquemas de aplicação devem assegurar que seus tipos são subtipos
dos correspondentes tipos da GML;
• Um esquema de aplicação não pode mudar o nome, definição ou tipo de dado dos
elementos obrigatórios da GML;
• Definições de tipos abstratos podem ser livremente estendidas ou restritas;
• Esquema de aplicação deve estar disponível a qualquer um que receba o dado
estruturado por aquele esquema; e
• Os esquemas relevantes devem especificar um namespace que não deve ser
http://www.opengis.net/gml.
Desta forma um desenvolvedor de esquemas pode criar seus próprios tipos e tags e uma
aplicação GML poderá fazer uso dos dados.
2.2.3.6 SLD (Styled Layer Descriptor)
Segundo OGC (2002), através do WMS é possível disponibilizar ao usuário opções de
estilo, no entanto o WMS pode fornecer ao usuário somente o nome de cada estilo. Não é possível
visualizar como cada estilo será apresentado no mapa. Mais importante, o usuário não pode definir
suas próprias regras de estilo. A aplicação de estilos pelo usuário requer a utilização de uma
linguagem de estilos que tanto o cliente quanto o servidor possam entender. Esta linguagem é
chamada de Styled Layer Descriptor (SLD).
De acordo com Aseefa e Mckenna (2005), o suporte ao SLD foi desenvolvido para o lado do
servidor (habilidade de ler um SLD e aplicar através de uma requisição GetMap) e para o lado do
cliente (inclui enviar uma requisição SLD para o servidor e gerar arquivos SLD em tempo de
execução a partir do mapfile).
Existem duas maneiras básicas de definir o estilo para um conjunto de dados. A maneira
mais simples é colorir todas features da mesma forma. Por exemplo, pode-se imaginar um layer
hidrografia consistido de linhas (rios) e polígonos (lagos, oceanos, etc). Um usuário pode informar
24
ao servidor que deseja colorir o interior de todos os polígonos com azul claro e a borda com azul
escuro. Isto é possível através do elemento FeatureTypeStyle no documento SLD (OGC, 2002).
Uma maneira mais complexa, é utilizar estilos diferentes de acordo com algum atributo. Por
exemplo, num conjunto de dados de ruas, utilizar: (1) um estilo para rodovias com uma linha
vermelha de três pixels; (2) aplicar um estilo de linha preta de dois pixels para ruas com uma pista;
e (3) ruas com duas pistas utilizar um estilo de linha preta de um pixel (ibidem).
Segundo OGC (2002), o WMS descreve a aparência de um mapa através de layers
utilizando estilos. Um layer utilizando estilo pode ser considerado como uma camada transparente.
Um mapa é feito de vários layers utilizando estilos colocados juntos em uma ordem específica. Os
usuários podem definir mapas mais ou menos complexos removendo ou inserindo novos layers com
estilos.
O layer pode ser simbolizado através da combinação de “layer” e “style”. Conceitualmente,
o layer define um conjunto de características e o style define como essas características serão
apresentadas. Este conceito é baseado no fato de que um layer pode ser apresentado de várias
maneiras distintas, de acordo com o style utilizado.
Na especificação WMS, a requisição de um mapa é codificada como um HTTP-GET e a
aparência do mapa é definida pelos parâmetros layers e styles. Este exemplo de requisição
(incompleta) a seguir:
http://yourfavoritesite.com/WMS?VERSION=1.1.0&REQUEST=GetMap&BBOX=0.0,0.0,
1.0,1.0&LAYERS=Rivers,Roads,Houses&STYLES=CenterLine,CenterLine,Outline
irá resultar no mapa mostrado abaixo.
25
Figura 7. Resultado de uma requisição SLD
Fonte: (OGC, 2002)
Neste mapa existem três layers:
1. Houses: Outline
2. Roads: CenterLine
3. Rivers: CenterLine
O layer Rivers: CenterLine está por baixo do layer Roads: CenterLine, pois o WMS plota
cada layer sucessivo acima do layer renderizado anteriormente. Consequentemente, as ruas
aparecem sobre os rios.
Um SLD inclui um elemento StyledLayerDescriptor que contém uma seqüência de
definições. O exemplo a seguir corresponde ao mapa apresentado anteriormente.
<StyledLayerDescriptorversion="1.0.0"> <NamedLayer> <Name>Rivers</Name> <NamedStyle> <Name>CenterLine</Name> </NamedStyle> </NamedLayer> <NamedLayer> <Name>Roads</Name> <NamedStyle> <Name>CenterLine</Name> </NamedStyle> </NamedLayer> <NamedLayer> <Name>Houses</Name> <NamedStyle> <Name>Outline</Name> </NamedStyle> </NamedLayer> </StyledLayerDescriptor>
Figura 8. Exemplo de arquivo SLD
26
Fonte: (OGC, 2002).
O SLD é estruturado conforme o padrão XML apresentado na Sub-seção 2.2.4 .
2.2.4 XML
O problema da interoperabilidade não é exclusividade para usuários de SIGs e sim uma
questão para todos os sistemas computacionais, e o padrão XML foi projetado com o propósito de
resolver este problema.
Segundo Benz e Durant (2003), o XML é usado para descrever documentos e dados
padronizados, em formato texto, que pode ser facilmente transportado via protocolos padrões de
Internet. Assim como o HTML, o XML é baseado no precursor de todas as linguagens de marcação,
o SGML. SGML é notável não somente porque foi a inspiração e a base para todas as linguagens de
marcação modernas, mas também pelo fato de o SGML ter sido criado em 1974 como parte de um
projeto da IBM de compartilhamento de documentos, tornando-se oficialmente um padrão ISO em
1986, muito antes de a Internet existir (BENZ e DURANT, 2003).
A primeira adaptação popular do SGML foi o HTML. Ele foi desenvolvido para padronizar
o formato de apresentação de documentos, ou seja, provê uma maneira padronizada de descrever a
disposição e apresentação de um documento. No entanto, não havia um padrão para descrever e
compartilhar dados que estavam armazenados no documento (ibidem). Em 1998, o W3C apresentou
a primeira recomendação do XML, que teve como pilares a extensibilidade, estrutura e validação.
Tais características são apresentadas através de uma ampla gama de recursos, como (PITTS-
MOULTIS E KIRK, 2000):
• Ser uma linguagem extensível que fornece a capacidade de definir suas próprias marcas
e atributos. Esses elementos e suas marcas de início e fim juntamente com seus atributos
o ajudam a definir os elementos estruturais do documento;
• Ter a capacidade de aninhar estruturas de documentos dentro das estruturas de outros
documentos.
O XML provê uma representação estruturada de dados que mostrou ser amplamente
implementável e fácil de ser desenvolvida. Uma característica importante é que uma vez tendo sido
recebido o dado pelo cliente, tal dado pode ser manipulado, editado e visualizado sem a necessidade
27
de reacionar o servidor. Dessa forma, os servidores têm menor sobrecarga, reduzindo a necessidade
de computação e reduzindo também a requisição de banda passante para as comunicações entre
cliente e servidor. (FURTADO, 2000)
Dentre os benefícios para desenvolvedores e usuários temos:
• Desenvolvimento de aplicações web mais flexíveis. Isso inclui integração de dados de
fontes completamente diferentes, de múltiplas aplicações; computação e manipulação
local dos dados; múltiplas formas de visualização e atualização granulares do conteúdo;
• Distribuição dos dados via rede de forma mais comprimida e escalável; e
• Padrões abertos.
2.2.4.1 Sintaxe XML
Cada documento XML começa com uma declaração, indicando que ele é de fato um
documento XML e informando para o parser a versão em que o documento está codificado. A
declaração é <?xml version=“1.0”?>.
Todo o conteúdo de um documento XML está contido entre tags. As tags são delimitadas
pelo caractere “<” e o caractere “>”, por exemplo <map>. As tags são usadas em pares, para cada
tag inicial <map>, deve haver uma final, da forma </map>. O dado fica entre as tags iniciais e
finais. Uma mesma tag pode ser repetida várias vezes e pode conter outras tags, que implementam
estruturas hierárquicas.
Desta forma, XML permite descrever dados através de tags criadas pelo usuário, por isso é
dita extensível. Na Figura 9 é apresentado um exemplo das tags juntamente com o seu conteúdo.
<map> <imagetype>png</imagetype> <size>400 400</size> <layer> <status> default </status> <type> polygon </type> <name> "limite_politico" </name> <data> "LIMITE_POLITICO_ADMINISTRATIVO" </data> <class> <name> "Limite Político Administrativo" </name> <color> 192 192 192 </color> <outlinecolor> 0 0 0 </outlinecolor> </class> </layer> </map>
Figura 9. Exemplo de tags em XML
28
Observando o exemplo apresentado na Figura 9, percebe-se que nenhuma tag pode ficar
aberta, ou seja, se a tag <imagetype> estivesse sem a tag de fechamento </imagetype>, o
documento estaria inconsistente. Também pode-se observar que as tags são fechadas na ordem em
que foram abertas, isso quer dizer que, ao serem abertas as tags <layer> e <class>, nesta ordem,
</class> deve ser fechada antes de </layer>.
Existe uma exceção para a regra de todas as tags possuírem obrigatoriamente uma abertura e
fechamento. O XML pode utilizar elementos vazios, ou seja, tags que não possuem conteúdo. Para
isso é utilizado o caractere “<”, uma seqüência alfanumérica, uma barra “/” e o caractere “>”.
A nomenclatura dos elementos XML deve seguir a seguinte regra: os nomes podem conter
letras, números e outros caracteres; não devem iniciar com um número ou pontuação; não devem
iniciar com as letras xml (ou XML ou Xml...); e nomes não podem possuir espaços. Além disso, o
nome dos elementos (tags) é case-sensitive, ou seja, o elemento <layer> é diferente do elemento
<Layer>.
Todo documento XML possui um elemento denominado elemento raiz, elemento principal
ou root e que não pode ser repetida. Isto significa que, o elemento principal guarda todo o conteúdo
de um documento XML. Os demais elementos componentes do documento são chamados de sub-
elementos, elementos aninhados ou elementos filhos.
Um documento XML bem formado é um documento que atende às regras de sintaxe XML:
• Deve começar com um declaração XML;
• Deve ter um elemento raiz único;
• Todas tags abertas precisam ser fechadas;
• Tags XML são sensíveis à caixa alta/baixa;
• Todo elemento deve ser fechado;
• Todo elemento tem que ser propriamente aninhado;
• Todos valores de atributos precisam estar entre aspas; e
• Entidades XML devem ser usadas para caracteres especiais.
29
Mesmo quando os documentos são bem formados eles podem conter erros que podem ter
conseqüências sérias. A seção a seguir apresenta as formas de validação de um arquivo XML.
2.2.4.2 Validação
Segundo Benz e Durant (2003), o XML é excelente para compartilhamento de dados
através de sistemas e plataformas. Entretanto, documentos XML que somente seguem as regras de
sintaxe são fáceis de gerar na fonte, mas normalmente muito difíceis de ler em seu destino sem
algum tipo de descrição da estrutura representada no documento XML. É nesse aspecto que entra a
questão da validação.
A validação utiliza um documento que descreve o formato e a estrutura de dados do
documento XML. Se o documento XML está formatado corretamente e o parser consegue
determinar que o documento está de acordo com a estrutura e formato descritos no documento de
validação, então o documento é dito como um XML válido (BENZ e DURANT, 2003).
Os dois tipos mais comuns usados para validar um XML são o DTD (Document Type
Definition) ou o XML Schema. Os documentos XML são comparados com regras que são
especificadas em um DTD ou Schema (ibidem).
DTD
O DTD foi originalmente desenvolvido como parte do SGML, e então estendido para a
recomendação W3C HTML para declarar qual especificação um documento HTML utiliza. Editores
HTML, browsers, e outros programas que validam a sintaxe de documentos HTML usam uma
referência opcional no topo de uma página HTML para identificar a versão do HTML com a
finalidade de renderização e validação. Os DTDs passaram a funcionar como documentos de
validação XML em 1998 como parte da recomendação W3C XML 1.0 (BENZ e DURANT, 2003).
Segundo W3schools (2005) o propósito de um DTD é definir os blocos de construção de um
documento XML. Ele define a estrutura do documento através de uma lista de elementos
permitidos. O DTD é uma forma de validar um documento XML.
O DTD é a base a partir da qual os documentos XML são criados, definindo as partes de um
documento e descreve como eles podem ou não ser usados, o que pode ser colocado em seus
interiores e se são ou não elementos obrigatórios do documento. Essencialmente, um DTD é um
conjunto de regras que define as instruções que serão enviadas ao analisador sintático para o
30
documento que está para ser analisado (PITTS-MOULTIS e KIRK, 2000). Eles são arquivos texto
que não seguem as mesmas regras de formatação de documentos XML.
Existem duas formas de um XML referenciar um DTD. O DTD pode ser incluído no
documento XML que ele descreve ou o documento pode usar um link para uma URL externa. Estes
DTDs externos podem ser compartilhados por diferentes documentos e web sites. Toda mudança
feita à um DTD externo é automaticamente propagada para todos documentos que utilizam este
DTD (HAROLD, 2004).
A Figura 10 apresenta um exemplo de arquivo DTD a fim de validar o documento XML
apresentado na Figura 9.
<?xml version="1.0" encoding="UTF-8"?> <!ELEMENT map (imagetype, size, layer)> <!ELEMENT layer (class, data, name, status, type)> <!ELEMENT class (color, name, outlinecolor)> <!ELEMENT imagetype (#PCDATA)> <!ELEMENT size (#PCDATA)> <!ELEMENT data (#PCDATA)> <!ELEMENT name (#PCDATA)> <!ELEMENT status (#PCDATA)> <!ELEMENT type (#PCDATA)> <!ELEMENT color (#PCDATA)> <!ELEMENT outlinecolor (#PCDATA)>
Figura 10. Exemplo de DTD para validar o XML da Figura 9
As linhas 2, 3 e 4 do DTD apresentado na Figura 10, especificam quais são os elementos
aninhados permitidos para, respectivamente, map, layer e class. No caso do elemento map, pode-se
observar que ele possui como sub-elementos imagetype, size e layer.
A linha 5, determina que o elemento imagetype é do tipo PCDATA (Parsed Character Data),
ou seja, um texto que irá passar pelo parser. O mesmo acontece para os elementos size, data, name,
status, type, color e outlinecolor.
31
XML Schema
XML Schema (também conhecido como XML Schema Definition - XSD) é um formato
atualizado para validação de documentos XML, sendo uma alternativa ao DTD. Diferentemente dos
DTDs, o formato do XML Schema segue as regras de sintaxe de documentos XML. Além disso, o
esquema permite um maior controle sobre os dados descritos (BENZ e DURANT, 2003). Assim
como o DTD, ele descreve a estrutura de um documento XML, definindo os blocos de construção
permitidos (W3SCHOOLS, 2005).
Através do XML Schema é possível definir os elementos que podem aparecer em um
documento, os atributos, os elementos filhos, a ordem dos elementos filhos, o número de elementos
filhos, se um elemento é vazio ou pode incluir texto, os tipos de dados para elementos e atributos,
valores padrão e fixos para elementos e atributos (W3SCHOOLS, 2005).
Quando um dado é enviado de um ponto para outro é essencial que as duas partes tenham a
mesma expectativa sobre o conteúdo. Com XML Schemas, o remetente pode descrever o dado de
forma que o receptor vá entender. Uma data como "03-11-2004" vai, em alguns países, ser
interpretada como 3 de Novembro e em outros com 11 de Março, mas um elemento XML com um
tipo de dado como <date type="date">2004-03-11</date> assegura um entendimento mútuo do
conteúdo porque o tipo de dado XML requer o formato YYYY-MM-DD.
XML Schemas são extensíveis, assim como XML, porque eles são escritos em XML. Dessa
maneira pode-se reutilizar o esquema em outros esquemas, criar tipos de dados derivados dos tipos
padrões e referenciar múltiplos esquemas em um mesmo documento.
A linguagem XML Schema divide os elementos em tipos complexos e simples. Um
elemento do tipo simples pode conter somente texto e não pode possuir atributos. Ele também não
pode possuir elementos filhos (aninhados). Entretanto, ele pode ser mais restrito ao tipo de texto
que pode conter. Por exemplo, um esquema pode definir que um elemento simples contém inteiro,
data, ou um valor decimal entre 4,45 e 18,64. Tipos complexos podem possuir atributos e elementos
filhos. A maioria dos documentos necessita de ambos, elementos complexos e simples (HAROLD,
2004).
Em um XML Schema todos os tipos de dados podem ser primitivos ou derivados. Os tipos
de dados primitivos são aqueles não se baseiam em outros tipos de dados, enquanto que os tipos de
32
dados derivados são aqueles baseados em outros tipos de dados. Por exemplo, o tipo de dado
integer baseia-se no tipo primitivo number, portanto ele é um tipo de dado derivado.
De acordo com Harold (2004), o XML Schema não está restrito aos tipos de dados nativos
da linguagem. Ele permite criar novos tipos de dados através da derivação de tipos de dados
existentes. O modo mais comum desta derivação é restringir o tipo para um subconjunto dos seus
valores. Por exemplo, pode-se definir um tipo inteiro que aceita somente números que estejam entre
1 e 10, utilizando-se do elemento xsd:restriction. A seguir é apresentado as três formas de criação
de novos tipos:
• xsd:restriction seleciona um subconjunto de valores permitidos pelo tipo base;
• xsd:union combina múltiplos tipos; e
• xsd:list especifica uma lista de elementos de um tipo simples existente.
A Figura 11 apresenta um fragmento de XML Schema para validação do XML apresentado
na Figura 9.
<xs:element name="map" type="maptype"/> <xs:complexType name="maptype"> <xs:sequence> <xs:element name="imagetype" type="imagetype_" minOccurs="0" maxOccurs="1"/> <xs:element name="size" type="xytype" minOccurs="0" maxOccurs="1"/> <xs:element name="layer" type="layertype" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="layertype"> <xs:sequence> <xs:element name="status" type="statustype" minOccurs="0" maxOccurs="1"/> <xs:element name="type" type="type_" minOccurs="0" maxOccurs="1"/> <xs:element name="name" type="stringtype" minOccurs="0" maxOccurs="1"/> <xs:element name="data" type="stringtype" minOccurs="0" maxOccurs="1"/> <xs:element name="class" type="classtype" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="classtype"> <xs:sequence> <xs:element name="name" type="stringtype" minOccurs="0" maxOccurs="1"/> <xs:element name="color" type="colortype" minOccurs="0" maxOccurs="1"/> <xs:element name="outlinecolor" type="colortype" minOccurs="0"/> </xs:sequence> </xs:complexType>
Figura 11. Exemplo de XML Schema para o XML da Figura 9
33
A linha 1 da Figura 11 define o elemento map como sendo o elemento raiz do documento.
Ele é do tipo maptype, que é especificado das linhas 2 à 8. Essa é uma das características do XML
Schema, ou seja, ele permite a criação de tipos personalizados. O elemento maptype possui
aninhados os elementos imagetype, size e layer, conforme mostra a Figura 11 nas linhas 4, 5 e 6
respectivamente.
Os elementos imagetype, size e layer são dos tipos imagetype_, xytype e layertype. Estes
encontram-se declarados no fragmento de XML Schema apresentado na Figura 12 a seguir.
<xs:complexType name="colortype"> <xs:sequence> <xs:element name="r" type="inttype" minOccurs="0"/> <xs:element name="g" type="inttype" minOccurs="0"/> <xs:element name="b" type="inttype" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:complexType name="xytype"> <xs:sequence> <xs:element name="x" type="inttype" minOccurs="0"/> <xs:element name="y" type="inttype" minOccurs="0"/> </xs:sequence> </xs:complexType> <xs:simpleType name="imagetype_"> <xs:restriction base="xs:string"> <xs:pattern value="gif|png|jpeg|wbmp|gtiff|swf|userdefined"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="statustype"> <xs:restriction base="xs:string"> <xs:pattern value="on|off|default"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="stringtype"> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="type_"> <xs:restriction base="xs:string"> <xs:pattern value="point|line|polygon|circle|annotation|raster|query"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="inttype"> <xs:restriction base="xs:int"/> </xs:simpleType>
Figura 12. Continuação do XML Schema apresentado na Figura 11
O tipo imagetype_ definido na linha 14 da Figura 12 apresenta mais uma característica
importante presente no XML Schema. Ele permite estender os tipos padrões. String, decimal,
integer, booleano, date e time são alguns deles. No caso do imagetype, ele estende o tipo string para
uma lista de possíveis valores.
34
Vantagens
De acordo com Benz e Durant (2003), os DTDs possuem uma grande desvantagem se
comparados ao XML Schema, pois ele exige que os elementos sejam texto, elementos aninhados ou
uma combinação de elementos aninhados e texto. DTDs também têm suporte limitado para tipos de
dados pré-definidos. Esquemas suportam todos tipos de atributo do DTD.
A primeira grande limitação dos DTDs que os desenvolvedores observaram foi a validação
de dados praticamente inexistente. Os DTDs não conseguem especificar que um elemento “preço”
deve conter um número, muito menos que este número deve ser maior que zero com duas casas
decimais de precisão. Além disso, o DTD não permite definir a ordem ou o número de filhos que
um elemento pode ter (HAROLD, 2004).
Segundo W3Schools (2005), o XML Schema foi originalmente proposto pela Microsoft,
mas se tornou uma recomendação oficial do W3C em Maio de 2001. A tendência é que em pouco
tempo ele substitua o DTD na maioria das aplicações web por razões como:
• São extensíveis para adições futuras;
• São mais ricos e úteis que DTDs;
• São escritos em XML;
• Suportam tipos de dados; e
• Suportam namespaces.
Há muitas razões para XML Schema ser melhor que DTD. Uma das grandes vantagens de
XML Schemas é o suporte a diferentes tipos de dados, porém merece destaque a facilidade com
que:
• Descrevem o conteúdo de documentos permissíveis
• Validam dos dados;
• Manipulam com dados de um banco de dados;
• Definem restrições aos dados;
• Definem padrões/formatos de dados; e
• Convertem dados entre diferentes tipos.
35
Outra grande força do XML Schema reside no fato de que ele é escrito em XML. Por isso
não é necessário aprender outra linguagem, qualquer editor pode ser utilizado para arquivos XML
Schema, o parser do XML pode ser usado para verificar arquivos XML Schema, a manipulação do
XML Schema pode ser feita com XML DOM e o XML Schema pode ser usado com XSLT.
A Seção 2.3 apresenta a linguagem C ANSI utilizada na implementação deste projeto.
2.3 C ANSI
Segundo Schildt (1991), a linguagem C foi inventada e implementada primeiramente por
Dennis Ritchie. C é o resultado de um processo de desenvolvimento que começou com uma
linguagem mais antiga, chamada BCPL, que ainda está em uso, em sua forma original, na Europa.
BCPL foi desenvolvida por Martin Richards e influenciou uma linguagem chamada B, inventada
por Ken Thompson. Na década de 1970, B levou ao desenvolvimento do C.
Por muitos anos, o padrão para C foi a versão fornecida com o sistema operacional UNIX
versão 5. Com a popularidade dos microcomputadores, um grande número de implementações de C
foi criado. Quase que por milagre, os códigos-fontes aceitos por essas implementações eram
altamente compatíveis (isto é, um programa escrito com um deles podia normalmente ser compilado
com sucesso usando-se um outro). Porém, por não existir nenhum padrão, havia discrepâncias. Para
remediar essa situação, o ANSI (American National Standards Institute) estabeleceu, no verão de
1983, um comitê para criar um padrão que definiria de uma vez por todas a linguagem C (ibidem).
36
2.4 Linguagens formais e compiladores
2.4.1 Compilador
Segundo Aho, Sethi e Ullman (1995) um compilador é um programa que transforma o
código escrito em linguagem (linguagem fonte) e o traduz num programa equivalente numa outra
linguagem (linguagem alvo), conforme mostra a Figura 13.
Figura 13. Um compilador
Fonte: Adaptado de Aho, Sethi e Ullman (1995).
Existem milhares de linguagens fonte, que vão das linguagens de programação tradicionais,
tais como Fortran e Pascal, às linguagens especializadas. As linguagens alvo são igualmente
variadas; uma linguagem alvo pode ser uma outra linguagem de programação ou a linguagem de
máquina de qualquer coisa entre um microprocessador e um supercomputador (AHO, SETHI e
ULLMAN, 1995).
A arquitetura convencional de um compilador divide-se em Análise e Síntese. A Análise
pode ser subdividida ainda em análise léxica, análise sintática e análise semântica. A Síntese é mais
variada, podendo ser composta pelas etapas de geração de código intermediário, otimização de
código e geração de código final (ou código de máquina). Somente esta última etapa é obrigatória.
2.4.1.1 Análise Léxica
Também chamada de análise linear ou esquadrinhamento (scanning), é a primeira fase de
um compilador. Como mostra a Figura 14, sua principal tarefa é a de ler os caracteres de entrada e
produzir uma seqüência de símbolos léxicos (lexical tokens) ou somente símbolos (tokens) que o
parser utiliza para a análise sintática (AHO, SETHI e ULLMAN, 1995).
37
Figura 14. Interação do analisador léxico com o parser
Fonte: Adaptado de Aho, Sethi e Ullman (1995).
Segundo Aho, Sethi e Ullman (1995), além disso, o analisador léxico também pode realizar
tarefas secundárias, como por exemplo: remover do programa-fonte os comentários e espaços em
branco, tabulações e caracteres de avanço de linha; correlacionar as mensagens de erro do
compilador com o programa-fonte.
De uma forma simplificada, pode-se dizer que o analisador léxico verifica se existe ou não
algum caractere que não faz parte do alfabeto da linguagem.
2.4.1.2 Análise Sintática
O analisador sintático obtém uma cadeia de tokens proveniente do analisador léxico e
verifica se a mesma pode ser gerada pela gramática da linguagem-fonte (ver Figura 15). Espera-se
que o analisador sintático relate quaisquer erros de sintaxe de uma forma inteligível. Deve também
se recuperar dos erros que ocorram mais comumente, a fim de poder continuar processando o resto
de sua entrada (AHO, SETHI e ULLMAN, 1995).
38
Figura 15. Posição de um analisador sintático num modelo de compilador
Fonte: Adaptado de Aho, Sethi e Ullman (1995).
2.4.1.3 Análise Semântica
Segundo Aho, Sethi e Ullman (1995), a análise semântica é a terceira fase da compilação
onde se verifica os erros semânticos (por exemplo, uma multiplicação entre tipos de dados
diferentes) no programa-fonte e captura as informações de tipo para a fase subseqüente da geração
de código. Utiliza a estrutura hierárquica determinada pela fase de análise sintática, a fim de
identificar os operadores e operandos das expressões e enunciados. É também na análise semântica
que são verificados os tipos. O compilador checa se cada operador recebe os operandos que são
permitidos pela especificação da linguagem fonte.
2.4.2 Flex & Bison
Segundo Mason, Levine e Brown (1995), o Flex e o Bison podem ajudar na escrita de
programas que transformam uma entrada estruturada. Isso inclui uma gama grande de aplicações,
desde um simples programa que procura por padrões em um arquivo texto de entrada até um
compilador C que transforma um programa fonte em um código objeto otimizado.
Em programas com entradas estruturadas, duas tarefas que ocorrem seguidamente são
dividir a entrada em unidades e descobrir o relacionamento entre estas unidades. Para um programa
de procura em texto, as unidades provavelmente serão linhas de texto, com distinção entre as linhas
que combinam com a string alvo e as linhas que não combinam. Para um programa C, as unidades
são nomes, constantes, strings, operadores, pontuação e assim por diante. Esta divisão em unidades
(que são usualmente chamadas de tokens) é conhecida como análise léxica, ou lexing. O Flex
39
auxilia na descrição dos possíveis tokens através de expressões regulares, produzindo uma rotina C,
que pode ser chamada de analisador léxico, lexer ou scanner, que identifica esses tokens (ibidem).
Como a entrada é dividida em tokens, um programa necessita estabelecer o relacionamento
entre os tokens. Um compilador C necessita encontrar expressões, instruções, declarações, blocos e
procedimentos no programa. Esta tarefa é conhecida como parsing, e a lista de regras que define os
relacionamentos que o programa entende é a gramática. O Bison utiliza uma descrição concisa de
uma gramática e produz uma rotina em C, chamada de parser. O parser detecta automaticamente se
uma seqüência de tokens entrada combina com uma das regras da gramática e também detecta erros
de sintaxe caso a entrada não combine com nenhuma das regras (MASON, LEVINE, e BROWN,
1995).
2.4.2.1 GNU Bison
O projeto GNU substituto para o Yacc é denominado Bison. GNU (Gnu’s Not Unix) é um
projeto da Free Software Foundation e é uma tentativa de criação de um sistema operacional Unix-
like com o código-fonte disponível publicamente.
O bison pode fazer o parsing da entrada de streams dotadas de tokens com certos valores.
Isto claramente descreve a relação que o Bison possui com o Flex. O Bison não reconhece streams
de entrada, ele precisa de tokens pré-processados.
Gramática
Para algumas aplicações, o reconhecimento de palavras pode ser adequado; outras precisam
reconhecer uma seqüência específica de tokens e realizar uma ação apropriada. Tradicionalmente, a
descrição de tal conjunto de ações é conhecido como gramática. Supondo que necessita-se
reconhecer as seguintes sentenças.
substantivo verbo. substantivo verbo substantivo.
É usado uma seta -> para representar que um conjunto de tokens pode ser substituído por
um símbolo. Por exemplo:
sujeito -> substantivo | pronome indica que um novo símbolo sujeito é um substantivo ou um pronome.
40
2.4.2.2 Flex
Uma versão livre do Lex é conhecida como Flex. Ele é uma versão do Lex distribuída com o
4.4BSD e pelo projeto GNU.
O programa Flex gera o que é chamado de lexer. Isto é, uma função que recebe uma stream
de caracteres de entrada e ao encontrar um grupo de caracteres que está de acordo com um padrão,
realiza uma determinada ação.
41
3 PROJETO
A modelagem do sistema tem como intuito apresentar o diagrama de seqüência e diagrama
de atividades demonstrando a interação do UMN Mapserver com a biblioteca proposta.
3.1 Diagrama de seqüência
Um Diagrama de Seqüência mostra a colaboração dinâmica entre os vários objetos de um
sistema. A partir dele percebe-se a seqüência de mensagens enviadas entre os objetos. Além disso,
ele mostra a interação entre os objetos, ou seja, algo que acontecerá em um ponto específico da
execução do sistema. O diagrama de seqüência consiste em um número de objetos mostrado em
linhas verticais. O decorrer do tempo é visualizado observando-se o diagrama no sentido vertical de
cima para baixo. As mensagens enviadas por cada objeto são simbolizadas por setas entre os objetos
que se relacionam.
O Diagrama de Seqüência ilustrado, na Figura 16, apresenta a troca de mensagens realizada
pelos diversos módulos do UMN Mapserver a fim de ler um arquivo de configuração de cartas
temáticas em XML e popular a estrutura (mapObj) que armazena o mapa.
sd Interactions
mapfile.c mapogcsld.c
valido:= validaArquivoXml(xmlpath, xmldata, mappath)
[valido == false]: msSetError(error)
[valido == true]: map:= msSLDApplySLDFile(map, layerIndex)
Figura 16. Diagrama de Seqüência para o módulo
A Tabela 2 apresenta a troca de mensagens para o Digrama de Seqüência da Figura 16.
Tabela 2. Troca de mensagens do diagrama de seqüência da Figura 16
ID Mensagem De Para Notas
1 ValidaArquivoXml mapfile.c mapfile.c Verifica se o documento XML
possui erros ou se ele não existe
no diretório apontado.
2 msSLDApplySLDFile mapfile.c mapogcsld.c Modifica o objeto map de acordo
com as configurações de estilo
contidas no documento XML.
3.2 Diagrama de atividades
Diagramas de Atividades capturam ações e seus resultados. Eles focam o trabalho executado
na implementação de uma operação (método), e suas atividades numa instância de um objeto. O
Diagrama de Atividade possui o propósito de capturar ações (trabalho e atividades que serão
executados) e seus resultados em termos das mudanças de estados e seus objetos.
A Figura 17 apresenta o Diagrama de Atividades que representa as operações e atividades
realizadas pelo UMN Mapserver para a leitura do arquivo XML de configuração dos parâmetros de
visualização das cartas temáticas.
43
ad Activ ity Diagram
Início
O mapserv er realiza a análiseléxica e sintática do mapfile
O mapserver faz a leitura dodocumento XML
Existemerros?Exibir erro
Existem erros?
Realiza ação solicitadapelo usuário
Fim
Não
Sim
Sim
Não
Figura 17. Diagrama de Atividades para o módulo
A seguir, são apresentadas as pré-condições.
O mapserver realiza a análise léxica e sintática do mapfile
Pré-condição: é necessário que o arquivo XML exista.
44
O mapserver faz a leitura do documento XML
Pré-condição: a análise léxica tenha retornado sucesso.
Realiza ação solicitada pelo usuário
As próximas ações a serem realizadas pelo UMN Mapserver dependem da requisição feita.
As principais ações são: gerar imagem, gerar legenda, gerar barras de escala e realizar pesquisas
geoespaciais.
3.3 Implementação
A proposta inicial do trabalho foi o desenvolvimento de uma biblioteca para o UMN
Mapserver, responsável pela leitura do arquivo de configuração escrito em XML, que substituiria
totalmente o arquivo de configuração existente, denominado mapfile. Após a leitura, os dados do
arquivo de configuração seriam incorporados à estrutura definida no código do UMN Mapserver.
No entanto, após o levantamento bibliográfico e o início da análise do código fonte do UMN
Mapserver, decidiu-se por manter o arquivo de configuração mapfile (adicionando um novo
atributo, denominado xmlpath, que aponta para o local onde estão armazenados os arquivos de
configuração do layer), utilizando um documento XML somente para a definição dos estilos de um
layer. Outro problema encontrado foi que a linguagem GML, definida inicialmente como padrão a
ser seguido para a definição do XML de estilos, não contempla a descrição de simbologias, e sim de
objetos geográficos. Desta forma foram pesquisadas novas alternativas e chegou-se à linguagem
SLD (Styled Layer Descriptor), que também é uma especificação do OGC. Os principais motivos
para estas mudanças foram:
• Realizar alterações mínimas no código do UMN Mapserver, facilitando a sua
incorporação pela comunidade de usuários e desenvolvedores;
• Falta de um padrão reconhecido pela OGC que contemplasse todas as necessidades do
mapfile; e
• Definição da especificação do OGC para estilos de layers, o SLD, como o padrão a ser
utilizado na configuração dos objetos layer do UMN Mapserver.
O UMN Mapserver, a partir da versão 4.4, suporta o uso de SLD tanto no lado servidor
quanto no lado cliente. Apesar do suporte ao SLD pelo UMN Mapserver, o problema ainda
continua, pois o ESRI ArcGis não possui suporte para SLD e nem o MapServer consegue ler um
45
SLD a partir de um arquivo gravado em disco. Dessa forma, ainda é necessário que o ESRI ArcGis
seja capaz de exportar de alguma forma as configurações feitas no layer e o UMN Mapserver leia
estas configurações.
Para isso, foi desenvolvida uma aplicação junto ao ESRI ArcGis utilizando a linguagem de
programação Visual Basic for Applications (ver Sub-seção 3.4.3 ). Ou seja, o usuário pode utilizar o
ESRI ArcGis para configurar o seu mapa e quando satisfeito, exportar esta configuração para um
documento XML que utiliza o padrão SLD. Então, o UMN Mapserver, através da biblioteca
desenvolvida (ver Sub-seção 0), é capaz de ler esse arquivo e apresentar o mapa da maneira como
foi configurado no ESRI ArcGis.
Para a leitura e interpretação do arquivo mapfile o UMN Mapserver utiliza-se de um
analisador sintático e um analisador léxico gerados a partir das ferramentas Flex & Bison.
3.4 Resultados
Os artefatos de software resultantes deste trabalho foram: (i) uma biblioteca em ANSI C
para o UMN Mapserver responsável pela leitura de arquivos XML utilizados na definição dos
objetos layer do mapfile; (ii) um módulo escrito na linguagem Visual Basic for Applications para a
criação do XML a partir das configurações de cartas temáticas realizadas pelo SIG residente ESRI
ArcGis; e (iii) uma aplicação webmapping para teste e validação da biblioteca.
Durante a fase de desenvolvimento, identificou-se a necessidade de utilização de
ferramentas que permitissem a criação de um analisador léxico utilizado pelo UMN Mapserver.
Optou-se por utilizar a ferramenta opensource Flex por esta já ser utilizada em módulos do UMN
Mapserver.
Uma grande dificuldade associada a implementação de bibliotecas para o UMN Mapserver
deve-se ao fato de este utilizar uma linguagem não orientada a objetos (ANSI C) e também por não
possuir documentação para o código fonte, somente os comentários no próprio código.
Os softwares desenvolvidos neste projeto serão melhores discutidos nas seções a seguir.
46
3.4.1 Visão geral das aplicações desenvolvidas
A fim de validar a biblioteca desenvolvida para o UMN Mapserver, ou seja, verificar se o
UMN Mapserver lê corretamente o arquivo de configuração escrito em XML utilizando o esquema
SLD, foi desenvolvida uma aplicação webmapping que será apresentada na Sub-seção 0.
Para gerar o documento XML a partir de uma aplicação externa, foi desenvolvido um
módulo para o ESRI ArcGis escrito em Visual Basic for Applications. Este módulo exporta as
configurações de estilo de um layer desejado para um documento XML. A Sub-seção 3.4.3
descreve o funcionamento deste módulo.
A Figura 18 apresenta como os sistemas interagem após o desenvolvimento do módulo para
o ESRI ArcGis e da biblioteca para o UMN Mapserver. O usuário pode fazer a configuração de
estilos e simbologia do layer através do ESRI ArcGis, e este, através do módulo, gera um
documento XML (SLD) que é lido pelo UMN Mapserver.
Aplicação SIG desktop (ArcGis)
Aplicação webgis
Módulo desenvolvido para o ArcGis
Documento XML gerado pelo módulo
UMN Mapserver
Mapfile
UMN Mapserver compilado com a biblioteca
Figura 18. Integração entre o ESRI ArcGis e o UMN Mapserver
47
3.4.2 Biblioteca para o UMN Mapserver
Para o desenvolvimento da biblioteca para o UMN Mapserver, inicialmente foi definido o
padrão a ser utilizado para escrever o arquivo de configuração de estilos das cartas temáticas. O
padrão escolhido foi o SLD (Styled Layer Definition), uma especificação do OGC para definição de
uma linguagem de estilos.
Tendo o padrão definido, foi alterado o analisador léxico do UMN Mapserver
(especificamente o arquivo maplexer.l) a fim de contemplar as mudanças necessárias no arquivo
mapfile. Para isto foi utilizado o software Flex, que baseado na nova configuração feita no
maplexer.l gerou o novo analisador léxico (maplexer.c) para a linguagem. A Figura 19 apresenta
um fragmento do arquivo maplexer.l, com as mudanças feitas em negrito.
... <INITIAL,OBJECT_STRING>connectiontype { return(CONNECTIONTYPE); } <INITIAL,OBJECT_STRING>data { return(DATA); } <INITIAL,OBJECT_STRING>xmldata { return(XMLDATA); } <INITIAL,OBJECT_STRING>datapattern { return(DATAPATTERN); } <INITIAL,OBJECT_STRING>debug { return(DEBUG); } <INITIAL,OBJECT_STRING>driver { return(DRIVER); } <INITIAL,OBJECT_STRING>dump { return(DUMP); } <INITIAL,OBJECT_STRING>empty { return(EMPTY); } ... <INITIAL,OBJECT_STRING>shadowcolor { return(SHADOWCOLOR); } <INITIAL,OBJECT_STRING>shadowsize { return(SHADOWSIZE); } <INITIAL,OBJECT_STRING>shapepath { return(SHAPEPATH); } <INITIAL,OBJECT_STRING>xmlpath { return(XMLPATH); } ...
Figura 19. Arquivo maplexer.l para a nova linguagem
Com essa mudança, o arquivo mapfile passa a possuir dois novos atributos: xmldata e
xmlpath. O elemento xmlpath deve apontar para o local onde estão localizados os documentos XML
de configuração. Quando o UMN Mapserver realiza a leitura de um arquivo mapfile, a cada layer
encontrado é identificado o nome do documento XML utilizado por ele através do elemento
xmldata. Então é feita a leitura do documento XML contendo a configuração de estilos e
armazenado os valores encontrados na estrutura interna do UMN Mapserver que controla o mapfile.
A Figura 20 apresenta quais as diferenças entre o arquivo mapfile antes das mudanças no analisador
léxico e após as mudanças. Pode-se observar que todas as configurações que antes eram realizadas
no elemento class do layer passam a ser feitas através do documento XML. Por questões de
compatibilidade, o usuário ainda pode realizar as configurações de estilo do layer através do
elemento class.
48
map extent -88 -33 -16 6 imagecolor 255 255 255 imagetype gif shapepath "shapes" size 400 400 status on units meters name "testing" debug on ... layer data "brasil97" name "brasil" sizeunits pixels status default type polygon class ... end class ... end class ... end end end
map extent -88 -33 -16 6 imagecolor 255 255 255 imagetype gif shapepath "shapes" xmlpath "xml" size 400 400 status on units meters name "testing" debug on ... layer name "brasil" data "brasil97" xmldata "brasil.sld" type polygon status default end end
Figura 20. Comparativo entre o mapfile antes da alteração no analisador léxico (à esquerda) e após as mudanças (à direita)
Após a leitura completa do mapfile e de cada um dos arquivos de configuração de estilo (um
documento XML para cada layer) é renderizada a imagem de saída e apresentada no browser do
usuário.
3.4.3 Módulo de geração de SLD para o ESRI ArcGis
A maior necessidade que impulsionou o desenvolvimento deste módulo foi que aplicações
SIG externas sejam capazes de exportar as definições de layer para um arquivo que o UMN
Mapserver pudesse ler e aplicar.
Para tanto, foi desenvolvido um módulo para o ESRI ArcGis que a partir das configurações
feitas pelo usuário em um mapa (cores, símbolos, etc), fosse gerado um documento XML que segue
o esquema SLD.
A Figura 21 apresenta a tela inicial do módulo de exportação, onde é apresentada uma lista
dos layers que o usuário está trabalhando no momento e pode-se selecionar quais serão exportados
para XML. Cada layer será exportado para um arquivo XML distinto.
49
Figura 21. Módulo de exportação desenvolvido para o ESRI ArcGis
Após selecionado qual layer deseja-se realizar a exportação, o módulo gera o documento
XML. A Figura 22 apresenta um exemplo de documento XML gerado pelo módulo. Este
documento XML é referente ao layer brasil (ver Figura 20).
<StyledLayerDescriptor version="1.0.0"> <NamedLayer> <Name>brasil</Name> <UserStyle> <Title>brasil</Title> <FeatureTypeStyle> <Rule> <Name>Acre</Name> <Filter> <PropertyIsEqualTo> <PropertyName>NOMEUF</PropertyName> <Literal>ACRE</Literal> </PropertyIsEqualTo> </Filter> <PolygonSymbolizer> <Geometry> <PropertyName>NOMEUF</PropertyName> </Geometry> <Fill> <CssParameter name="fill">#5D7CBA</CssParameter> </Fill> <Stroke> <CssParameter name="stroke">#543C1C</CssParameter> <CssParameter name="stroke-width">1.0</CssParameter> </Stroke> </PolygonSymbolizer> </Rule> <Rule> <Name>Santa Catarina</Name> <Filter> <PropertyIsEqualTo> <PropertyName>NOMEUF</PropertyName> <Literal>SANTA CATARINA</Literal> </PropertyIsEqualTo> </Filter> <PolygonSymbolizer> <Geometry>
50
<PropertyName>NOMEUF</PropertyName> </Geometry> <Fill> <CssParameter name="fill">#A97838</CssParameter> </Fill> <Stroke> <CssParameter name="stroke">#543C1C</CssParameter> <CssParameter name="stroke-width">1.0</CssParameter> </Stroke> </PolygonSymbolizer> </Rule> <Rule> <Name>Outros</Name> <ElseFilter/> <PolygonSymbolizer> <Geometry> <PropertyName>NOMEUF</PropertyName> </Geometry> <Fill> <CssParameter name="fill">#FFE3BF</CssParameter> </Fill> <Stroke> <CssParameter name="stroke">#543C1C</CssParameter> <CssParameter name="stroke-width">1.0</CssParameter> </Stroke> </PolygonSymbolizer> </Rule> </FeatureTypeStyle> </UserStyle> </NamedLayer> </StyledLayerDescriptor>
Figura 22. Documento XML gerado pelo módulo
3.4.4 Aplicação webmapping
Após desenvolvida a biblioteca para leitura de arquivos XML pelo UMN Mapserver, foi
feita uma aplicação para testá-la. Para o teste da biblioteca foram utilizados três arquivos shape, um
de linhas (batimetria), um de polígonos (brasil) e um de pontos (capitais), obtidos do site do IBGE.
Foi utilizado o UMN Mapserver no modo CGI (Sub-seção 2.1.1 ), compilado com a
biblioteca desenvolvida. Neste modo o UMN Mapserver é acionado através de uma chamada ao
seu executável pela URL do browser.
Para a apresentação visual da aplicação, foi construído um template html que é apresentado
na Figura 23.
<html> <!--http://localhost/cgi-bin/mapserv.exe?map=../htdocs/tcc/teste.map&mode=browse--> <head> <title>TCC II - Jeferson Koslowski</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <link type="text/css" rel="stylesheet" href="/tcc/css/template.css" />
51
<script language="JavaScript" type="text/javascript" src="/tcc/js/webgis.js"></script> </head> <body bgcolor="#FFFFFF" text="#000000" leftmargin="0" topmargin="0" onload="javascript:resize()"> <form name="mapserv" method="GET" action="/cgi-bin/mapserv.exe"> <input type="hidden" name="map" value="[map]"/> <input type="hidden" name="imgext" value="[mapext]"/> <input type="hidden" name="imgxy" value="[center]"/> <input type="hidden" name="mode" value="browse"/> <input type="hidden" name="layers" value="" /> <input type="hidden" name="zoom" value="0"/> <input type="hidden" name="mapsize" value="[mapwidth] [mapheight]"/> <div id="webgis"> <div class="banner"></div> <div class="mapa" id="mapa" style="z-index:1"> <input type="image" name="img" src="[img]" border="0" width="[mapwidth]" height="[mapheight]"> </div> <div class="ferramentas" id="ferramentas"> <input type="button" value="" id="zoommais" class="zoommais" onclick="javascript:aproxima();"> <input type="button" value="" id="zoommenos" class="zoommenos" onclick="javascript:afasta();"> </div> <div class="cabecalho"></div> <div class="legenda" id="legenda"> [legend] <br> <center> <input class="bt" type="button" value="Atualizar" id="atualizar" class="atualizar" onclick="javascript:submit();"> </center> </div> <div class="referencia" id="referencia"> <input type="image" name="img" src="[ref]" border="0"> </div> <div class="escala" id="escala"> <center> <input type="image" name="img" src="[scalebar]" border="0"> </center> </div> </div> </form> </body> </html>
Figura 23. Template construído para a aplicação webgis
Através do mapfile é definido qual template será usado pela aplicação. Quando o UMN
Mapserver encontra as tags “[“ e “]” dentro do template, ele substitui seus valores. Dessa forma, ao
encontrar a tag [img], por exemplo, o UMN Mapserver substitui seu valor pelo caminho da imagem
gerada. Para a construção da legenda do mapa, também foi utilizado um template (ver Figura 24).
[leg_layer_html opt_flag=2] <input type="checkbox" name="layers" value=[leg_layer_name] [if name=layer_status oper=eq value=1]checked[/if]><span class="tema">[leg_layer_name]</span><br> [/leg_layer_html]
52
[leg_class_html opt_flag=2] <img src=[leg_icon]><span class="classe"> [leg_class_name]</span><br> [/leg_class_html]
Figura 24. Template utilizado para desenhar a legenda do mapa
A Figura 25 mostra a aplicação webmapping utilizada para testar a biblioteca.
Figura 25. Aplicação webmapping desenvolvida para teste da biblioteca
53
4 CONCLUSÃO
O UMN Mapserver é uma ferramenta opensource e possui suporte de uma grande
comunidade de desenvolvedores. Além disso, o Laboratório de Computação Aplicada desenvolve
sistemas utilizando-se desta ferramenta há alguns anos.
A falta de documentação do código-fonte do UMN Mapserver bem como as várias
mudanças ao longo do projeto a fim de seguir os padrões estabelecidos pela OGC foram dois
grandes problemas encontrados ao longo do desenvolvimento. Outra grande dificuldade foi a
impossibilidade de fazer a depuração do código, pois para a compilação do UMN Mapserver
utilizou-se o Microsoft Visual Studio em modo console. No entanto, essas dificuldades não
impediram a conclusão deste projeto e alcançar os objetivos propostos.
Na definição de um padrão para configuração dos parâmetros de visualização de cartas
temáticas, optou-se pelo SLD, especificado pelo OCG, por ele ser aceito por entidades
internacionais e usado em muitos Sistemas de Informações Geográficas.
Através do estudo das tecnologias apresentadas neste projeto, foi possível o
desenvolvimento da biblioteca em linguagem C ANSI para leitura de arquivos de configuração dos
parâmetros de visualização de cartas temáticas no UMN Mapserver em documentos XML.
Com este projeto fica claro que a padronização é importante quando se trata de
interoperabilidade entre Sistemas de Informações Geográficas. Foi possível identificar também, que
já existem organizações responsáveis por tais padronizações e o que se busca neste momento é que
esses padrões sejam realmente implementados.
Dessa forma, pode-se afirmar que o presente trabalho deu um passo em busca deste objetivo,
permitindo o compartilhamento das configurações de estilo das layers entre um dos principais SIGs
residentes (ESRI ArcGis) e o servidor de mapas utilizado para a construção de aplicações
webmapping (o UMN Mapserver).
A aprovação da biblioteca proposta neste trabalho junto ao comitê gestor do UMN
Mapserver será uma importante conquista na busca pela interoperabilidade entre os diversos
Sistemas de Informações Geográficas, permitindo que os desenvolvedores de outros SIGs residentes
disponibilizem módulos para a geração dos arquivos XML contendo a configuração de estilos das
cartas temáticas.
Além disso, deve-se considerar o desenvolvimento de scripts para geração do arquivo de
configuração por outros SIG’s residentes que não o ESRI ArcGis, como o Jump, o Grass, o Spring,
entre outros.
Por fim, buscar a aprovação da biblioteca pela comunidade Mapserver: este procedimento é
feito através do commit do código no repositório CVS do UMN Mapserver (o Laboratório de
Computação Aplicada – LCA possui acesso liberado ao CVS) e posteriormente ele será submetido à
aprovação.
55
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT. Normalização. São Paulo: ABNT, [ca.2000]. Disponível em: <http://www.abnt.org.br/normal_oque.htm>. Acesso em: 10 jun. 2005.
AHO, Alfred V.; SETHI, Ravi; ULLMAN, Jeffrey D. Compiladores: princípios, técnicas e ferramentas. Rio de Janeiro: Livros Técnicos e Científicos, 1995.
ANSI. Frequently asked questions. Washington: ANSI, 2005. Disponível em: <http://www.ansi.org/about_ansi/faqs/faqs.aspx?menuid=1>. Acesso em: 7 jun. 2005.
ASSEFA, Yewondwossen; MCKENNA, Jeff. MapServer Styled Layer Descriptor (SLD) HOWTO. [S.l.: s.n.], 2005. Disponível em: <http://mapserver.gis.umn.edu/doc46/sld-howto.html>. Acesso em: 10 nov. 2005.
BENZ, Brian; DURANT, John R. XML Programming Bible. Indianapolis: Wiley Publishing, 2003.
BURROUGH, P. A. Principles of geographic information systems for land resources assessment. Oxford: Clarendon Press, 1986.
COX, Simon; DAISEY, Paul; LAKE, Ron; PORTELE, Clemens; WHITESIDE, Arliss. Geography Markup Language (GML). v.3.1.0. [S.l.]: ISO, 2004.
DAVIS JÚNIOR, Clodoveu A.; BORGES, Karla A. V.; SOUZA, Ligiane Alves; CASANOVA, Marco Antonio; LIMA JÚNIOR, Paulo de Oliveira. O Open Geospatial Consortium. [S.l.: s.n], 2005. Disponível em: <http://www.dpi.inpe.br/livros/bdados/cap11.pdf>. Acesso em: 15 maio 2005.
DOYON, Jean-François; MCKENNA, Jeff. MapFile Reference: MapServer 4.4. [S.l.: s.n.], 2004. Disponível em: <http://mapserver.gis.umn.edu/doc44/mapfile-reference.html>. Acesso em: 12 maio 2005.
FURTADO, Danilo; NICOLAU, Rita; ROSÁRIO, Lúcio do; FONSECA, Alexandra; ALVES, Patrícia. Desertificação: índices de susceptibilidade e sua exploração utilizando ferramentas de webmapping. Lisboa: Instituto Geográfico Português, 2004. Disponível em: <http://www.igeo.pt/IGEO/portugues/servicos/CDI/biblioteca/PublicacoesIGP_files/ESIG_2004/p056.pdf>. Acesso em: 30 maio 2005.
FURTADO, Miguel Benedito Júnior. XML: extensible markup language. Rio de Janeiro: [s.n], [ca.2000]. Disponível em: <http://www.gta.ufrj.br/grad/00_1/miguel/>. Acesso em: 02 mar. 2005.
HAROLD, Elliotte Rusty. XML 1.1 Bible. Indianapolis: Wiley Publishing, 2004.
HELLSTRÖM, Gunnar. Standardization: what is standardization and why you have to follow technical standards?. Johanneshov: Omnitor AB, 2005. Disponível em: <http://www.omnitor.se/english/standards/>. Acesso em: 7 jun. 2005.
ISO. Overview of the ISO system. Geneva: ISO, 2005. Disponível em: <http://www.iso.ch/iso/en/aboutiso/introduction/index.html>. Acesso em: 7 jun. 2005.
JACOBS, Ian. About the World Wide Web Consortium (W3C). Cambridge: W3C, 2005. Disponível em: <http://www.w3.org/Consortium/Overview>. Acesso em: 12 jun. 2005.
KANEGAE, Eduardo Patto. Democratizando a geoinformação através do webmapping. [S.l.: s.n], 2003. Disponível em: <http://www.webmapit.com.br/index.php?option=com_content&task=view&id=34&Itemid=48&lang=pt_BR>. Acesso em: 01 jun. 2005.
LIMA JÚNIOR, Paulo de Oliveira; CÂMARA, Gilberto. GeoBR: intercâmbio sintático e semântico de dados espaciais. Informática Pública, v.4, n.2, p.251-281, 2002. Disponível em: <http://www.ip.pbh.gov.br/revista0402/ip0402oliveira.pdf>. Acesso em: 06 maio 2005.
MAPSERVER. Mapserver. Minnesota: MAPSERVER, 2005. Disponível em: <http://mapserver.gis.umn.edu/>. Acesso em: 14 jun. 2005.
MASON, Tony; LEVINE, John R; BROWN, Doug. Lex & YACC. 2nd. ed. Sebastopol (California): O Reilly Ass, 1995.
OGC. Resources - Frequently Asked Questions. [S.l.]: OGC, 2005. Disponível em: <http://www.opengeospatial.org/resources/?page=faq#8>. Acesso em: 08 jun. 2005.
OGC. Styled Layer Descriptor Implementation Specification. United States: OGC, 2002. Disponível em: <http://www.opengeospatial.org/docs/02-070.pdf>. Acesso em: 10 nov. 2005.
PITTS-MOULTIS, Natanya; KIRK, Cheryl. XML black book: solução e poder. São Paulo: Makron Books, 2000.
RAMSEY, Paul. The state of Open Source GIS. [S.l.]: Refractions Research, 2005. Disponível em: <http://www.refractions.net/white_papers/oss_briefing/2005-02-OSS-Briefing.pdf>. Acesso em: 10 jun. 2005.
SCHILDT, Herbert. C completo e total. Sao Paulo: Makron Books, 1991.
SEBRAE. Normalização. Florianópolis: SEBRAE, 2004. Disponível em: <http://www.sebrae-sc.com.br/sebraetib/>. Acesso em: 7 jun. 2005.
SHEKHAR, Shashi; VATSAVAL, Ranga Raju; SAHAY, Namita; BURK, Thomas E.; LIME, Stephen. WMS and GML based interoperable web mapping system. Minneapolis: University of Minnesota, 2001. Disponível em: <http://www-users.cs.umn.edu/~vatsavai/papers/acmgis01-raju.pdf>. Acesso em: 12 jun. 2005.
SILVA, Grace Kelly de Castro; PEREIRA, Patrícia Maria. Disponibilização de serviços baseados em localização via web services. In: SIMPÓSIO BRASILEIRO DE GEOINFORMÁTICA, 6., 2004, Campos do Jordão. Anais eletrônicos... Campos do Jordão: GeoInfo, 2004. Disponível em: <http://www.geoinfo.info/geoinfo2004/papers/6392.pdf>. Acesso em: 09 jun. 2005.
UCHOA, Helton Nogueira; FERREIRA, Paulo Roberto. Geoprocessamento com Software Livre. v.1.0. [S.l.: s.n.], 2004. Disponível em: <http://www.geolivre.org.br/downloads/
57
geoprocessamento_software_livre_Uchoa-Roberto-v1.0.pdf>. Acesso em: 04 maio 2005.
VRETANOS, Panagiotis A. Web Feature Service Implementation Specification. v.1.1.0. [S.l.]: OGC, 2005.
W3SCHOOLS. Tutorial XML schema. Tradução Maurício M. Maia. [S.l.: s.n.], 2005. Disponível em: <http://www.dicas-l.unicamp.br/dicas-l/20050326.php>. Acesso em: 05 mar. 2005.
58
APÊNDICES
A ARTIGO CIENTÍFICO
ANEXOS
I XML SCHEMA DO PADRÃO SLD
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://www.opengis.net/sld" xmlns:sld="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xsd:import namespace="http://www.w3.org/1999/xlink" schemaLocation="../../gml/2.1.1/xlinks.xsd"/> <xsd:import namespace="http://www.opengis.net/ogc" schemaLocation="../../filter/1.0.0/filter.xsd"/> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> STYLED LAYER DESCRIPTOR version 1.0.0 (2002-09-21) </xsd:documentation> </xsd:annotation> <xsd:element name="StyledLayerDescriptor"> <xsd:annotation> <xsd:documentation> A StyledLayerDescriptor is a sequence of styled layers, represented at the first level by NamedLayer and UserLayer elements. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name" minOccurs="0"/> <xsd:element ref="sld:Title" minOccurs="0"/> <xsd:element ref="sld:Abstract" minOccurs="0"/> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="sld:NamedLayer"/> <xsd:element ref="sld:UserLayer"/> </xsd:choice> </xsd:sequence> <xsd:attribute name="version" type="xsd:string" use="required" fixed="1.0.0"/> </xsd:complexType> </xsd:element> <xsd:element name="Name" type="xsd:string"/> <xsd:element name="Title" type="xsd:string"/> <xsd:element name="Abstract" type="xsd:string"/> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> LAYERS AND STYLES </xsd:documentation> </xsd:annotation> <xsd:element name="NamedLayer"> <xsd:annotation> <xsd:documentation> A NamedLayer is a layer of data that has a name advertised by a WMS. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name"/> <xsd:element ref="sld:LayerFeatureConstraints" minOccurs="0"/> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="sld:NamedStyle"/> <xsd:element ref="sld:UserStyle"/> </xsd:choice>
</xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="NamedStyle"> <xsd:annotation> <xsd:documentation> A NamedStyle is used to refer to a style that has a name in a WMS. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="UserLayer"> <xsd:annotation> <xsd:documentation> A UserLayer allows a user-defined layer to be built from WFS and WCS data. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name" minOccurs="0"/> <xsd:element ref="sld:RemoteOWS" minOccurs="0"/> <xsd:element ref="sld:LayerFeatureConstraints"/> <xsd:element ref="sld:UserStyle" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="RemoteOWS"> <xsd:annotation> <xsd:documentation> A RemoteOWS gives a reference to a remote WFS/WCS/other-OWS server. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Service"/> <xsd:element ref="sld:OnlineResource"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Service"> <xsd:annotation> <xsd:documentation> A Service refers to the type of a remote OWS server. </xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="WFS"/> <xsd:enumeration value="WCS"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="OnlineResource"> <xsd:annotation> <xsd:documentation> An OnlineResource is typically used to refer to an HTTP URL. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attributeGroup ref="xlink:simpleLink"/> </xsd:complexType> </xsd:element> <xsd:element name="LayerFeatureConstraints">
63
<xsd:annotation> <xsd:documentation> LayerFeatureConstraints define what features & feature types are referenced in a layer. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:FeatureTypeConstraint" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="FeatureTypeConstraint"> <xsd:annotation> <xsd:documentation> A FeatureTypeConstraint identifies a specific feature type and supplies fitlering. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:FeatureTypeName" minOccurs="0"/> <xsd:element ref="ogc:Filter" minOccurs="0"/> <xsd:element ref="sld:Extent" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="FeatureTypeName" type="xsd:string"/> <xsd:element name="Extent"> <xsd:annotation> <xsd:documentation> An Extent gives feature/coverage/raster/matrix dimension extent. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name"/> <xsd:element ref="sld:Value"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Value" type="xsd:string"/> <xsd:element name="UserStyle"> <xsd:annotation> <xsd:documentation> A UserStyle allows user-defined styling and is semantically equivalent to a WMS named style. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name" minOccurs="0"/> <xsd:element ref="sld:Title" minOccurs="0"/> <xsd:element ref="sld:Abstract" minOccurs="0"/> <xsd:element ref="sld:IsDefault" minOccurs="0"/> <xsd:element ref="sld:FeatureTypeStyle" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="IsDefault" type="xsd:boolean"/> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> FEATURE-TYPE STYLING </xsd:documentation> </xsd:annotation> <xsd:element name="FeatureTypeStyle">
64
<xsd:annotation> <xsd:documentation> A FeatureTypeStyle contains styling information specific to one feature type. This is the SLD level that separates the 'layer' handling from the 'feature' handling. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name" minOccurs="0"/> <xsd:element ref="sld:Title" minOccurs="0"/> <xsd:element ref="sld:Abstract" minOccurs="0"/> <xsd:element ref="sld:FeatureTypeName" minOccurs="0"/> <xsd:element ref="sld:SemanticTypeIdentifier" minOccurs="0" maxOccurs="unbounded"/> <xsd:element ref="sld:Rule" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="SemanticTypeIdentifier" type="xsd:string"/> <xsd:element name="Rule"> <xsd:annotation> <xsd:documentation> A Rule is used to attach property/scale conditions to and group the individual symbolizers used for rendering. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Name" minOccurs="0"/> <xsd:element ref="sld:Title" minOccurs="0"/> <xsd:element ref="sld:Abstract" minOccurs="0"/> <xsd:element ref="sld:LegendGraphic" minOccurs="0"/> <xsd:choice minOccurs="0"> <xsd:element ref="ogc:Filter"/> <xsd:element ref="sld:ElseFilter"/> </xsd:choice> <xsd:element ref="sld:MinScaleDenominator" minOccurs="0"/> <xsd:element ref="sld:MaxScaleDenominator" minOccurs="0"/> <xsd:element ref="sld:Symbolizer" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="LegendGraphic"> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Graphic"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="ElseFilter"> <xsd:complexType/> </xsd:element> <xsd:element name="MinScaleDenominator" type="xsd:double"/> <xsd:element name="MaxScaleDenominator" type="xsd:double"/> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> SYMBOLIZERS </xsd:documentation> </xsd:annotation> <xsd:element name="Symbolizer" type="sld:SymbolizerType" abstract="true"/> <xsd:complexType name="SymbolizerType" abstract="true"> <xsd:annotation> <xsd:documentation> A "SymbolizerType" is an abstract type for encoding the graphical properties used to portray geographic information. Concrete symbol
65
types are derived from this base type. </xsd:documentation> </xsd:annotation> </xsd:complexType> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> LINE SYMBOLIZER </xsd:documentation> </xsd:annotation> <xsd:element name="LineSymbolizer" substitutionGroup="sld:Symbolizer"> <xsd:annotation> <xsd:documentation> A LineSymbolizer is used to render a "stroke" along a linear geometry. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="sld:SymbolizerType"> <xsd:sequence> <xsd:element ref="sld:Geometry" minOccurs="0"/> <xsd:element ref="sld:Stroke" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="Geometry"> <xsd:annotation> <xsd:documentation> A Geometry gives reference to a (the) geometry property of a feature to be used for rendering. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="ogc:PropertyName"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Stroke"> <xsd:annotation> <xsd:documentation> A "Stroke" specifies the appearance of a linear geometry. It is defined in parallel with SVG strokes. The following CssParameters may be used: "stroke" (color), "stroke-opacity", "stroke-width", "stroke-linejoin", "stroke-linecap", "stroke-dasharray", and "stroke-dashoffset". </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:choice minOccurs="0"> <xsd:element ref="sld:GraphicFill"/> <xsd:element ref="sld:GraphicStroke"/> </xsd:choice> <xsd:element ref="sld:CssParameter" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="CssParameter"> <xsd:annotation> <xsd:documentation> A "CssParameter" refers to an SVG/CSS graphical-formatting parameter. The parameter is identified using the "name" attribute and the content of the element gives the SVG/CSS-coded value.
66
</xsd:documentation> </xsd:annotation> <xsd:complexType mixed="true"> <xsd:complexContent> <xsd:extension base="sld:ParameterValueType"> <xsd:attribute name="name" type="xsd:string" use="required"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:complexType name="ParameterValueType" mixed="true"> <xsd:annotation> <xsd:documentation> The "ParameterValueType" uses WFS-Filter expressions to give values for SLD graphic parameters. A "mixed" element-content model is used with textual substitution for values. </xsd:documentation> </xsd:annotation> <xsd:sequence minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="ogc:expression"/> </xsd:sequence> </xsd:complexType> <xsd:element name="GraphicFill"> <xsd:annotation> <xsd:documentation> A "GraphicFill" defines repeated-graphic filling (stippling) pattern for an area geometry. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Graphic"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="GraphicStroke"> <xsd:annotation> <xsd:documentation> A "GraphicStroke" defines a repated-linear graphic pattern to be used for stroking a line. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Graphic"/> </xsd:sequence> </xsd:complexType> </xsd:element> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> POLYGON SYMBOLIZER </xsd:documentation> </xsd:annotation> <xsd:element name="PolygonSymbolizer" substitutionGroup="sld:Symbolizer"> <xsd:annotation> <xsd:documentation> A "PolygonSymbolizer" specifies the rendering of a polygon or area geometry, including its interior fill and border stroke. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="sld:SymbolizerType"> <xsd:sequence> <xsd:element ref="sld:Geometry" minOccurs="0"/> <xsd:element ref="sld:Fill" minOccurs="0"/>
67
<xsd:element ref="sld:Stroke" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="Fill"> <xsd:annotation> <xsd:documentation> A "Fill" specifies the pattern for filling an area geometry. The allowed CssParameters are: "fill" (color) and "fill-opacity". </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:GraphicFill" minOccurs="0"/> <xsd:element ref="sld:CssParameter" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> POINT SYMBOLIZER </xsd:documentation> </xsd:annotation> <xsd:element name="PointSymbolizer" substitutionGroup="sld:Symbolizer"> <xsd:annotation> <xsd:documentation> A "PointSymbolizer" specifies the rendering of a "graphic symbol" at a point. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="sld:SymbolizerType"> <xsd:sequence> <xsd:element ref="sld:Geometry" minOccurs="0"/> <xsd:element ref="sld:Graphic" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="Graphic"> <xsd:annotation> <xsd:documentation> A "Graphic" specifies or refers to a "graphic symbol" with inherent shape, size, and coloring. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="sld:ExternalGraphic"/> <xsd:element ref="sld:Mark"/> </xsd:choice> <xsd:sequence> <xsd:element ref="sld:Opacity" minOccurs="0"/> <xsd:element ref="sld:Size" minOccurs="0"/> <xsd:element ref="sld:Rotation" minOccurs="0"/> </xsd:sequence> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Opacity" type="sld:ParameterValueType"/>
68
<xsd:element name="Size" type="sld:ParameterValueType"/> <xsd:element name="Rotation" type="sld:ParameterValueType"/> <xsd:element name="ExternalGraphic"> <xsd:annotation> <xsd:documentation> An "ExternalGraphic" gives a reference to an external raster or vector graphical object. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:OnlineResource"/> <xsd:element ref="sld:Format"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Format" type="xsd:string"/> <xsd:element name="Mark"> <xsd:annotation> <xsd:documentation> A "Mark" specifies a geometric shape and applies coloring to it. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:WellKnownName" minOccurs="0"/> <xsd:element ref="sld:Fill" minOccurs="0"/> <xsd:element ref="sld:Stroke" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="WellKnownName" type="xsd:string"/> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> TEXT SYMBOLIZER </xsd:documentation> </xsd:annotation> <xsd:element name="TextSymbolizer" substitutionGroup="sld:Symbolizer"> <xsd:annotation> <xsd:documentation> A "TextSymbolizer" is used to render text labels according to various graphical parameters. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="sld:SymbolizerType"> <xsd:sequence> <xsd:element ref="sld:Geometry" minOccurs="0"/> <xsd:element ref="sld:Label" minOccurs="0"/> <xsd:element ref="sld:Font" minOccurs="0"/> <xsd:element ref="sld:LabelPlacement" minOccurs="0"/> <xsd:element ref="sld:Halo" minOccurs="0"/> <xsd:element ref="sld:Fill" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="Label" type="sld:ParameterValueType"> <xsd:annotation> <xsd:documentation> A "Label" specifies the textual content to be rendered. </xsd:documentation> </xsd:annotation> </xsd:element>
69
<xsd:element name="Font"> <xsd:annotation> <xsd:documentation> A "Font" element specifies the text font to use. The allowed CssParameters are: "font-family", "font-style", "font-weight", and "font-size". </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:CssParameter" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="LabelPlacement"> <xsd:annotation> <xsd:documentation> The "LabelPlacement" specifies where and how a text label should be rendered relative to a geometry. The present mechanism is poorly aligned with CSS/SVG. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice> <xsd:element ref="sld:PointPlacement"/> <xsd:element ref="sld:LinePlacement"/> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="PointPlacement"> <xsd:annotation> <xsd:documentation> A "PointPlacement" specifies how a text label should be rendered relative to a geometric point. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:AnchorPoint" minOccurs="0"/> <xsd:element ref="sld:Displacement" minOccurs="0"/> <xsd:element ref="sld:Rotation" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="AnchorPoint"> <xsd:annotation> <xsd:documentation> An "AnchorPoint" identifies the location inside of a text label to use an an 'anchor' for positioning it relative to a point geometry. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:AnchorPointX"/> <xsd:element ref="sld:AnchorPointY"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="AnchorPointX" type="sld:ParameterValueType"/> <xsd:element name="AnchorPointY" type="sld:ParameterValueType"/> <xsd:element name="Displacement"> <xsd:annotation> <xsd:documentation> A "Displacement" gives X and Y offset displacements to use for rendering a text label near a point. </xsd:documentation> </xsd:annotation>
70
<xsd:complexType> <xsd:sequence> <xsd:element ref="sld:DisplacementX"/> <xsd:element ref="sld:DisplacementY"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="DisplacementX" type="sld:ParameterValueType"/> <xsd:element name="DisplacementY" type="sld:ParameterValueType"/> <xsd:element name="LinePlacement"> <xsd:annotation> <xsd:documentation> A "LinePlacement" specifies how a text label should be rendered relative to a linear geometry. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:PerpendicularOffset" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="PerpendicularOffset" type="sld:ParameterValueType"> <xsd:annotation> <xsd:documentation> A "PerpendicularOffset" gives the perpendicular distance away from a line to draw a label. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="Halo"> <xsd:annotation> <xsd:documentation> A "Halo" fills an extended area outside the glyphs of a rendered text label to make the label easier to read over a background. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:Radius" minOccurs="0"/> <xsd:element ref="sld:Fill" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Radius" type="sld:ParameterValueType"/> <!-- *********************************************************************** --> <xsd:annotation> <xsd:documentation> RASTER SYMBOLIZER </xsd:documentation> </xsd:annotation> <xsd:element name="RasterSymbolizer" substitutionGroup="sld:Symbolizer"> <xsd:annotation> <xsd:documentation> A "RasterSymbolizer" is used to specify the rendering of raster/ matrix-coverage data (e.g., satellite images, DEMs). </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="sld:SymbolizerType"> <xsd:sequence> <xsd:element ref="sld:Geometry" minOccurs="0"/> <xsd:element ref="sld:Opacity" minOccurs="0"/> <xsd:element ref="sld:ChannelSelection" minOccurs="0"/> <xsd:element ref="sld:OverlapBehavior" minOccurs="0"/> <xsd:element ref="sld:ColorMap" minOccurs="0"/>
71
<xsd:element ref="sld:ContrastEnhancement" minOccurs="0"/> <xsd:element ref="sld:ShadedRelief" minOccurs="0"/> <xsd:element ref="sld:ImageOutline" minOccurs="0"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="ChannelSelection"> <xsd:annotation> <xsd:documentation> "ChannelSelection" specifies the false-color channel selection for a multi-spectral raster source. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice> <xsd:sequence> <xsd:element ref="sld:RedChannel"/> <xsd:element ref="sld:GreenChannel"/> <xsd:element ref="sld:BlueChannel"/> </xsd:sequence> <xsd:element ref="sld:GrayChannel"/> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="RedChannel" type="sld:SelectedChannelType"/> <xsd:element name="GreenChannel" type="sld:SelectedChannelType"/> <xsd:element name="BlueChannel" type="sld:SelectedChannelType"/> <xsd:element name="GrayChannel" type="sld:SelectedChannelType"/> <xsd:complexType name="SelectedChannelType"> <xsd:sequence> <xsd:element ref="sld:SourceChannelName"/> <xsd:element ref="sld:ContrastEnhancement" minOccurs="0"/> </xsd:sequence> </xsd:complexType> <xsd:element name="SourceChannelName" type="xsd:string"/> <xsd:element name="OverlapBehavior"> <xsd:annotation> <xsd:documentation> "OverlapBehavior" tells a system how to behave when multiple raster images in a layer overlap each other, for example with satellite-image scenes. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice> <xsd:element ref="sld:LATEST_ON_TOP"/> <xsd:element ref="sld:EARLIEST_ON_TOP"/> <xsd:element ref="sld:AVERAGE"/> <xsd:element ref="sld:RANDOM"/> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="LATEST_ON_TOP"> <xsd:complexType/> </xsd:element> <xsd:element name="EARLIEST_ON_TOP"> <xsd:complexType/> </xsd:element> <xsd:element name="AVERAGE"> <xsd:complexType/> </xsd:element> <xsd:element name="RANDOM"> <xsd:complexType/> </xsd:element> <xsd:element name="ColorMap"> <xsd:annotation>
72
<xsd:documentation> A "ColorMap" defines either the colors of a pallet-type raster source or the mapping of numeric pixel values to colors. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="sld:ColorMapEntry"/> </xsd:choice> </xsd:complexType> </xsd:element> <xsd:element name="ColorMapEntry"> <xsd:complexType> <xsd:attribute name="color" type="xsd:string" use="required"/> <xsd:attribute name="opacity" type="xsd:double"/> <xsd:attribute name="quantity" type="xsd:double"/> <xsd:attribute name="label" type="xsd:string"/> </xsd:complexType> </xsd:element> <xsd:element name="ContrastEnhancement"> <xsd:annotation> <xsd:documentation> "ContrastEnhancement" defines the 'stretching' of contrast for a channel of a false-color image or for a whole grey/color image. Contrast enhancement is used to make ground features in images more visible. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:choice minOccurs="0"> <xsd:element ref="sld:Normalize"/> <xsd:element ref="sld:Histogram"/> </xsd:choice> <xsd:element ref="sld:GammaValue" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="Normalize"> <xsd:complexType/> </xsd:element> <xsd:element name="Histogram"> <xsd:complexType/> </xsd:element> <xsd:element name="GammaValue" type="xsd:double"/> <xsd:element name="ShadedRelief"> <xsd:annotation> <xsd:documentation> "ShadedRelief" specifies the application of relief shading (or "hill shading") to a DEM raster to give it somewhat of a three-dimensional effect and to make elevation changes more visible. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element ref="sld:BrightnessOnly" minOccurs="0"/> <xsd:element ref="sld:ReliefFactor" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="BrightnessOnly" type="xsd:boolean"/> <xsd:element name="ReliefFactor" type="xsd:double"/> <xsd:element name="ImageOutline"> <xsd:annotation> <xsd:documentation> "ImageOutline" specifies how individual source rasters in a multi-raster set (such as a set of satellite-image scenes)
73
should be outlined to make the individual-image locations visible. </xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice> <xsd:element ref="sld:LineSymbolizer"/> <xsd:element ref="sld:PolygonSymbolizer"/> </xsd:choice> </xsd:complexType> </xsd:element> </xsd:schema>
74
