SOFTWARE LIVRE NA ÁREA DE SIG: FICÇÃO OU REALIDADE? Claudia de Andrade Tambascia, Lin Tzy Li, Marta Duarte Teixeira, Rafael de Melo Cuba e Sandro Danilo Gatti DSSO, SIGPPT. {claudiat,lintzyli,madute,rafael,gatti}@cpqd.com.br Abstract. This article presents main free software projects related to GIS (Geographical Information Systems) area, addressing spatial database, basic tools and applications for mapping and viewing spatial data. This paper will focus on how interoperability concept and international initiatives for open standards have contributed to the growth of GIS free software. Due to the CPqD's large experience in developing coorporative critical mission solutions based on geospatial data processing, mainly in the telecommunications field, it was possible to CPqD to do research in free software and opened standards for geographic information systems. As the result of those studies, a set of tools has been developed, attesting its competence to offer solutions in distinctive projects as city halls, smaller business and telecommunications public politics for the Brazilian Ministry of the Communications through SIGPPT project, which in portuguese stands for geographic information system for telecommunications public politics. Resumo. Este artigo apresenta os principais projetos de software livre na área de SIG (Sistema de Informações Geográficas), abordando banco de dados espaciais, bibliotecas, softwares básicos de infra-estruturas e aplicativos de visualização de mapas. Será dado um foco especial em como conceitos de interoperabilidade e iniciativas internacionais para definição de padrões abertos têm contribuído para o crescimento de software livre na área SIG Sistemas de Informações Geográficas. Com a experiência do CPqD no desenvolvimento de soluções coorporativas e de missão crítica baseadas em manipulação de informações georeferenciadas na área de telecomunicações, foi possível alavancar pesquisas em software livre e padrões abertos para sistemas de informações geográfica. Os impactos desta atuação forneceram ferramental para atuar em projetos de contexto diferenciado do quadro corporativista, como prefeituras, empresas de menor porte e também em políticas públicas de telecomunicações junto ao Ministério das Comunicações através do projeto SIGPPT. 1. Introdução A notícia de que o software livre tem revolucionado o mercado de software já não é mais novidade para a grande maioria de desenvolvedores e usuários de software, principalmente pela gama de produtos opensource, que vão de simples editores de texto a robustos servidores de aplicação.
A definição de padrões abertos para Sistemas de Informações Geográficas (SIG), principalmente pelo OpenGeospatial Consortium (OGC) [1], tem possibilitado não apenas a interoperabilidade entre sistemas, no sentido de comunicação e troca de dados, mas também a definição de arquiteturas SIG baseadas em componentes. E é neste aspecto que a combinação software livre e padrões abertos se torna muito interessante para toda comunidade SIG, pois impulsiona o trabalho tanto da comunidade de Software Livre como do OGC, buscando a comprovação prática de suas especificações. Empresas de desenvolvimento de soluções SIG ganham agilidade no processo de implementação e flexibilidade para decidirem onde utilizar software livre em uma solução SIG. Componentes opensource podem ser incorporados como parte de uma solução comercial ou mesmo utilizados na definição de uma arquitetura SIG totalmente opensource. Os resultados das pesquisas apresentados nesse artigo, relacionados a definição de arquiteturas SIG baseadas em componentes e definição de tecnologias envolvidas no desenvolvimento de software livre, agregam valor aos sistemas existentes ao viabilizar o desenvolvimento de aplicações SIG com softwares livres e padrões abertos internacionais para obter interoperabilidade entre sistemas, além da flexibilidade de se compôr uma solução SIG mais adequada através de componentes. Na seção 2 desse artigo será apresentado o conceito de software livre, definições importantes e suas categorias. Na seção 3 será apresentada as tecnologias envolvidas no desenvolvimento de software livre. Na seção 4 será apresentado como construir uma solução SIG utilizando componentes livres. Na seção 5 são detalhados os produtos, componentes e bibliotecas de Software Livre para SIG. Na seção 6 será apresentado a conclusão do trabalho que foi realizado.
2. Software Livre O Software Livre (SL) hoje não é mais uma tendência, e sim uma realidade. Sistemas proprietários têm perdido mercado ininterruptamente, e não há mais como ignorar as alterações e mudanças de paradigma que o SL tem feito na computação e até mesmo na sociedade [22]. Diversos fóruns, encontros técnicos, seminários, eventos e projetos de lei em vários países (nos quais o Brasil está inserido) mostram o espaço que o SL tem conquistado e a velocidade com o qual tem angariado adeptos, de diretores de TI a usuários finais, como é o caso do Geoinfo e GeoBrasil, das listas de discussão de Software Livre, etc. O rápido fluxo de informação entre os envolvidos nesse ambiente comumente citado como a sinergia da comunidade de SL e o baixo custo das licenças tem sido as principais alavancas para a disseminação dessa tecnologia. A viabilidade de uso de software livre em projetos críticos, com rígidas exigências de desempenho, escalabilidade, recuperabilidade e disponibilidade já é fato para inúmeros sistemas em operação. Contudo, é importante salientar que uma visão radical nesta questão pode determinar o fracasso de um projeto. Apregoar a eliminação de software pago/proprietário e adoção indiscriminada de software livre pode ser um equívoco, pelo menos no cenário atual. Cada sistema tem suas peculiaridades, necessidades, público alvo, dentre outros requisitos. O SL deve ser considerado como uma possível solução, sem obviamente ignorar suas casuais limitações e dificuldades, como tipos de licença, funcionalidades existentes, nível de suporte técnico e maturidade do produto.
2.1. Definições Relacionadas a SL, alguns termos são bastante utilizados, como código fonte, código executável, pacote, licença e distribuição, que serão definidos a seguir Código fonte: código em uma determinada linguagem de programação de alto nível, que pode ser entendida por serem humanos. Código executável: gerado em formato binário para ser executado em um computador. Pacote: programa ou um conjunto de programas/softwares Licença: grau de liberdade que quem adquiriu um produto possui com relação ao seu código. Distribuição: conjunto de pacotes (customizados) disponíveis em meio físico ou para download (baixer localmente) de forma que seja possível a sua instalação em computadores. 2.2. Categoria de softwares Existem diversas categorias de software, seja este livre ou não, que são apresentadas da Tabela 1. Software Livre Software de código aberto Software de domínio público Tabela 1 Definição das categorias de software [16] Permite que qualquer pessoa use, copie e distribua o código original ou com modificações, gratuitamente ou através de uma taxa. Para tal, o código fonte do software deve estar disponível. Deve-se entender livre como liberdade de expressão e não a preço. Programa distribuído com seu respectivo código, de forma que seja possível estudar, entender e alterar este código, dependendo da licença do software. Softwares não associados a nenhum direito autoral (copyright), mas não são necessariamente softwares livres. Se um software é de domínio público e o respectivo código fonte está disponível, trata-se então de um caso especial chamado de software livre non-copylefted.
Software Livre Software livre com Copyleft Software livre sem Copyleft Software GPL Sistema GNU Software semi-livre Software particular Permite que qualquer pessoa use, copie e distribua o código original ou com modificações, gratuitamente ou através de uma taxa. Para tal, o código fonte do software deve estar disponível. Deve-se entender livre como liberdade de expressão e não a preço. Método para fazer com que um programa seja considerado livre e garantir que todas suas cópias e redistribuições sejam livres também. Os termos de distribuição de um software copylefted não permitem que pessoas que redistribuam cópias (originais ou modificadas) do software adicionem restrições ao uso. Permite que se distribua e copie o software, possibilitando adicionar restrições ao seu uso. Assim sendo, se um software livre não possui copyleft pode ser que versões modificadas do software tornem-se proprietárias. Licença pública que possui um conjunto de termos de distribuição pra tornar um programa copylefted. Sistema operacional Unix completo e livre. Software que não é considerado livre, mas permite o uso, cópia, distribuição e modificação desde que não haja o propósito de obter lucro. Desenvolvido por um usuário (tipicamente uma empresa), não disponibilizando o código do software para o público. As categorias de software particular são divididas em: software proprietário (precisa comprar licença de uso); freeware (distribuição e uso gratuitos); shareware (livre por um determinado tempo) e software comercial (desenvolvido com o intuito de obter dinheiro). As diferenças entre os termos software livre (free software) e código aberto (open source) tem sido alvo de discussões nos últimos anos. Open Source não é sinônimo para Livre. Software Livre é um termo consagrado, muito bem definido e utilizado. Open Source por outro lado é um termo mercadológico, dando a idéia de que o código fonte está disponível, o que é uma questão muito diferente da "liberdade" defendida pelo software livre. Existem inúmeras formas de utilização de SL dentro dos mais diversos nichos de mercado, englobando ferramentas de desenvolvimento, componente funcional, plataformas, bibliotecas, produtos e fonte de capacitação. Apesar de muitos ainda considerarem SL apenas em sistemas operacionais, dado crescimento da popularidade
das distribuições do sistema operacional GNU/Linux, eles não estão restritos a este tipo de software. Dentro de cada uma dessas classificações, os SLs tem características próprias, seja pela licença, seja pela maturidade do software tanto em termos de implementação quanto documentação, seja pelo nicho de mercado que atua ou mesmo pelo suporte informal oferecido pelos usuários através de listas de discussão. Essas características são fundamentais quando da avaliação de um SL, pois produtos com mais funcionalidades podem mostrar-se menos robustos, assim como produtos com licenças menos custosas podem, eventualmente, possuir suporte de pior qualidade. 3. Tecnologias envolvidas no desenvolvimento de software livre 3.1. J2EE A tecnologia J2EE e seu modelo baseado em componente simplificam o desenvolvimento e a distribuição de soluções corporativas. A plataforma J2EE controla a infra-estrutura e suporta os Web Services para permitir o desenvolvimento de aplicações seguras, robustas e interoperante. J2EE prove várias facilidades como: soluções de time do market ; liberdade de escolha de plataforma de execução, pois segue uma especificação implementada por diversos fornecedores; e simplicidade de conectividade, garantindo uma padronização da arquitetura para soluções corporativas através de dois componentes essenciais que são HTTP e XML. 3.2. Arquitetura Uma arquitetura bem pensada e estruturada é essencial para o sucesso de uma aplicação. Os tipos de arquitetura existentes englobam arquitetura centralizada,
arquitetura em duas camadas, arquitetura em 3 camadas, arquitetura em 3/4 camadas Web-Based e arquitetura distribuída em n camadas. Atender as pressões do negócio e as pressões tecnológicas é um desafio constante as empresas. Para tanto, requisitos como: melhor flexibilidade, adaptabilidade, manutenabilidade, reusabilidade, aproveitamento do legado, interperabilidade, escalabilidade, robustez e menor tempo de desenvolvimento e risco, são necessários para minimizar as pressões, satisfazendo o que a ISO-9126 caracteriza como qualidade de software. Todas estas características de arquitetura multicamada e modularizada em componentes facilitou o desenvolvimento do movimento de software livre, pois cada pessoa pode se concentrar em fazer uma parte, o que não era muito fácil em uma arquitetura centralizada, e isto se refletiu nos software para SIG. Hoje é possível construir uma solução SIG com componentes livres [17]. 4. Como construir uma solução SIG utilizando componentes livres Conceitualmente, arquiteturas SIG são formadas por vários componentes como sistema de armazenamento de dados espaciais, servidores de mapas e dados e aplicações cliente e Web para visualização e manipulação de dados. Fazendo uma breve análise das arquiteturas SIG existentes, é bem provável que elas difiram entre si na maioria dos seguintes aspectos: representação de estilo, formato dos mapas, representação das geometrias, armazenamento de dados espaciais e formato de imagens raster. Somando a esta série de variáveis as diferentes linguagens de programação, plataformas e interfaces de comunicação, não é difícil compreender porque, na prática, o conceito de reuso de componentes no contexto SIG pareça tão inviável.
A definição de padrões abertos para SIG, principalmente pelo OpenGeospatial Consortium (OGC)[1], tem possibilitado não apenas a interoperabilidade entre sistemas, no sentido de comunicação e troca de dados, mas também a definição de arquiteturas SIG baseadas em componentes, conforme ilustrado na Figura 1. Figura 1 Soluções SIG[17] 4.1. Padrões OpenGIS A Figura 2 apresenta os principais padrões definidos pelo OGC, que vem impulsionando o desenvolvimento de componentes de SL para a área de SIG e serão detalhados a seguir. Estes padrões também vem sendo adotado por empresas como Oracle, IBM, Autodesk, ESRI, MapInfo, etc no desenvolvimento de seus produtos, o que torna real a interoperabilidade e a flexibilidade de se combinar diferentes componentes de software que implementam o padrão OpenGIS. Figura 2 Visão geral sobre o uso de padrões OGC em soluções SIG [17]
4.1.1. Simple Features (SFS) O objetivo da especificação Simple Features for SQL (SFS) [7][18] é definir um esquema no padrão SQL que suporte o armazenamento, recuperação, consulta e atualização de coleções de objetos (features) geo-espaciais através de uma API ODBC. Um objeto simples (simple feature) possui, segundo a definição da especificação OpenGIS, atributos espaciais e não-espaciais. Atributos espaciais possuem valor geométrico e uma simple feature é baseada em uma geometria bidimensional com interpolação linear entre os vértices. 4.1.2. Geography Markup Language (GML) GML é uma codificação XML para o transporte e armazenamento de informações geográficas, incluindo tanto as propriedades espaciais quanto as não espaciais de objetos geográficos, também chamados de feições geográficas (geographic features). Feição geográfica é uma representação abstrata dos fenômenos do mundo real e está associada a uma localização relativa à Terra. 4.1.3. Filter Encoding (Filter) A especificação OGC Filter Encoding define um vocabulário XML para a construção de filtros [4]. Um filtro é uma estrutura utilizada para descrever restrições, formadas por propriedades alfanuméricas e espaciais dos objetos, com o propósito de identificar um subconjunto de um determinado tipo de objeto (feature type). 4.1.4. Styled Layer Descriptor (SLD) A especificação Styled Layer Descriptor (SLD) [2][20] considera dois aspectos distintos, que envolvem uma linguagem para representação de estilos e layers e interfaces necessárias para utilização destes conceitos em um servidor de mapas (WMS). O padrão SLD define um esquema XML para representação de layers e estilos.
4.1.5. Web Feature Services (WFS) A especificação Web Feature Services [5][19] define interfaces para que dados de um servidor de objetos espaciais (features) possam ser acessados. As requisições e respostas devem ser feitas utilizando-se HTTP. Esquema GML e XML são utilizados para representação de meta-informação e dados, respectivamente. O padrão OGC Filter Encoding é utilizado para representação de consultas. Estes serviços podem ser requisitados por uma aplicação cliente utilizando, respectivamente, as seguintes interfaces definidas pela especificação WFS: GetCapabilities, DescribeFeatureType e GetFeature. 4.1.5.1. Transaction WFS (WFS-T) Um servidor de features transacional (WFS-T) implementa todas as interfaces de um servidor Basic WFS e acrescenta suporte a transações, permitindo que features sejam modificadas no servidor. 4.1.5.2. Cliente WFS Um cliente WFS é qualquer aplicativo que se comunica com um ou mais servidores WFS utilizando as interfaces definidas no padrão WFS. A partir destas interfaces, é possível criar aplicações para consultar e modificar as features do servidor WFS, conforme ilustrado na Figura 3. Client WFS Request WFS Response Web Feature Server (WFS) Opaque Feature Store Figura 3 Cliente WFS [5][19]
4.1.6. Web Map Services (WMS) A especificação Web Map Services [3][19] padroniza interfaces que devem ser utilizadas por clientes para requisitar os mapas aos servidores e o modo como estes servidores devem descrever e retornar estes mapas. É capaz de gerar mapas georreferenciados (como uma imagem ou um conjunto de objetos gráficos), retornar informações sobre objetos apresentados no mapa e descrever quais mapas ele pode produzir e quais podem ou não ter seus objetos consultados, para que um cliente deste servidor saiba quais mapas podem ser solicitados. 4.1.6.1. WMS SLD-Enabled O comportamento de um servidor WMS pode ser estendido permitindo que o estilo seja informado na requisição GetMap, dando ao usuário a opção de definir com que aparência os objetos (features) armazenados no servidor devem ser desenhados no mapa. A descrição deste estilo é feita utilizando a linguagem SLD definida pelo OGC na especificação Styled Layer Descriptor, ou seja, um servidor WMS SLD-Enabled recupera as features de um servidor WFS e aplica a definição de estilo, fornecido em formato SLD, gerando um mapa. 4.1.6.2. Cliente WMS Um cliente WMS é qualquer aplicação que se comunica com um ou mais servidores de mapas através das interfaces definidas pela especificação WMS. Assim, uma das questões que deve ser tratada por um cliente WMS é organizar as imagens (layers) retornadas pelas requisições GetMap, compondo o mapa, conforme ilustrado na Figura 5. Figura 5 Cliente WMS [3][19]
4.1.6.3. WMS Cascade WMS Cascading é um WMS que disponibiliza acesso a vários outros WMS em um único servidor. Este nível de abstração torna mais simples alterações na configuração dos servidores: sem o conhecimento do cliente, servidores WFS e WMS podem ser adicionados e removidos. Em alguns casos, um WMS Cascading supre algumas deficiências de outros WMS que não podem, por exemplo, publicar dados em determinada projeção ou formato. Um WMS Cascading atua como um cliente para os demais servidores WMS e um servidor para o cliente, conforme ilustrado na Figura 6. Figura 6 WMS Cascade [19] 4.1.7. Web Map Context (WMC) A especificação WMS especifica como um determinado servidor de mapas descreve e fornece seus mapas. A especificação OGC Web Map Context (WMC) [12] define como um conjunto de um ou mais mapas provenientes de um ou mais servidores WMS pode ser descrito em um formato independente de plataforma para
armazenamento e transmissão. Para isto, é definido um documento XML denominado Context. Um documento Context inclui informações como: servidores que fornecem as layers que compõe o mapa, área geográfica (extent) que deve ser apresentada, sistema de coordenadas de visualização, tamanho do mapa. 4.2. Produtos, componentes e bibliotecas de Software Livre para SIG 4.2.1. SGDBs Sistemas Gerenciadores de Banco de Dados 4.2.1.1. MySQL O SGBD MySQL [8][15] surgiu a partir de um grupo de desenvolvedores que havia implementado rotinas de baixo nível (ISAM) e usavam o msql para conectar as tabelas. Após alguns testes, foi verificado a necessidade do desenvolvimento de uma nova interface SQL para o banco de dados a fim de ganhar desempenho e mais flexibilidade, surgindo assim um SGBD com uma arquitetura bem simples e leve, focado no desempenho, no mercado há mais de dez anos. O MySQL disponibiliza um mecanismo de controle de permissões através de máquinas e usuários, além de todo tráfego de dados (senhas, por exemplo) serem criptografados durante a transferência. Em termos de volume dados, há bancos de dados MySQL com mais de 60.000 tabelas e 5 bilhões de linhas, fato que atesta a capacidade de armazenagem de grande volume de dados. A versão 5.0 do MySQL permite a criação de código armazenado (stored procedures) no servidor de banco de dados, mas a funcionalidade ainda não está madura. O código está sendo desenvolvido de acordo com o SQL:2003. O MySQL possui suporte nativo a tratamento de dados espaciais a partir de versão 4.1, sem a necessidade de nenhuma instalação de módulos adicionais. Contudo,
nas versões atuais (5.0 e 4.1) não é possível criar tabelas geo-referenciadas que suportam transação, como tabelas do tipo InnoDB. O MySQL implementa o suporte a dados espaciais seguindo um subconjunto da especificação do OGC SFS [7]. 4.2.1.2. PostgreSQL O PostgreSQL [9] é um Sistema de Gerenciamento de Banco de Dados Objeto- Relacional (SGBDOR) baseado no projeto POSTGRES, o qual foi iniciado em 1986 e desenvolvido no departamento de Ciência da Computação da Universidade da Califórnia (Berkeley). O PostgreSQL suporta os padrões SQL92 e SQL99 e funcionalidades importantes, como: chaves estrangeiras, gatilhos, visões, integridade transacional, controle de concorrência com multiversionamento, dentre outras. É possível também criar novos tipos de dados, funções, operadores, funções de agregação, índices e ainda código armazenado (stored procedures) em linguagens como PL/pgSQL, Tcl, Perl e Python. Implementa, também, conceitos de orientação a objetos, como herança, funcionalidade que pode ser usada de forma inteligente e possibilitar a criação de modelos de banco de dados interessantes. Há tipos geométricos nativos, como point, box, lseg, line, path, polygon, e circle, além de inúmeras funções geométricas, operadores para relacionar estes tipos, e funções para conversão de tipos. O PostgreSQL implementa operadores que possibilitam recuperar a distância entre dois objetos, o ponto mais próximo de um objeto dentro de uma região, o centróide de um objeto, verificar se um objeto sobrepõe outro, se são paralelos, está contido, entre outros. Porém, as funcionalidades geométricas podem ser melhoradas se for instalada a
extensão PostGIS [10], que adiciona uma série de tipos para manipulação de dados geográficos. Os tipos de dados e funções nativas do PostgreSQL não são suficientes para operações de grande complexidade, além de não contemplarem a especificação do OpenGIS SFS [7]. Sem dúvida, a utilização de PostGIS é a escolha a ser feita quando se pensa em usar o PostgreSQL como SGBD em um ambiente de SIG. A versão 8.0 do PostgreSQL, lançada em abril de 2005, além de estar disponível nativamente para Windows, adiciona savepoints, que permitem que uma transação seja desfeita até determinado checkpoint; point-in-time recovery, que permite backup contínuo do banco de dados e melhora a disponibilidade do sistema; tablespaces, que permitem um melhor gerenciamento dos arquivos de dados e uma grande melhora de desempenho. Estas funcionalidades anteriormente estavam restritas apenas a SGBDs comerciais como o Oracle. Quanto à arquitetura, o PostgreSQL usa o modelo cliente/servidor, de forma que os processos clientes e servidor não precisam necessariamente estar na mesma máquina. Neste caso, eles se comunicam via rede através do protocolo TCP/IP. 4.2.1.3. PostGIS Existem alguns tipos e funções para tratamento de dados geográficos já disponíveis no PostgreSQL. Porém, o PostGIS estende o PostgreSQL com funções adicionais, tabelas de metadados e objetos geográficos, tornando o PostgreSQL compatível com a OGC SFS e fazendo-o um SGBD apto para ser utilizado em um SIG [10][15]. É necessário, entretanto, deixar claro que deve-se instalar bibliotecas adicionais para que o PostGIS consiga demonstrar todo o seu potencial, como a biblioteca GEOS, um port C++ da JTS - Java Topology Suit, que oferece suporte às funções definidas no SFS. O PostGIS permite representar objetos em duas e três dimensões, além de poder
representá-los nos padrões WKT e WKB, Well-Known Text e Well-Known Binary, respectivamente, ambos padrões especificados pelo OGC. Para carregar dados espaciais para o SGBD, é disponibilizado o aplicativo shp2pgsql, o qual converte ESRI shapefiles para SQL, caso não exista previamente um arquivo SQL com os comandos de inserção (INSERTS). Para recuperar informações geográficas da base de dados pode-se usar comandos SQL ou mesmo o aplicativo pgsql2shp. Em relação à indexação espacial, o PostGIS permite a utilização de índices de árvore R ou índices GiST (Generalized Search Trees). Este último, mais robusto, divide o dado em objetos que estão em um lado, objetos que sobrepõe, objetos que estão contidos e, desta forma, pode ser usado em uma vasta gama de situações. Os dados espaciais podem ser acessados por vários tipos de processos cliente, desde o MapServer até clientes Java (via JDBC). O PostgreSQL/PostGIS, apesar de aceitar tipos de dados espaciais e um conjunto grande de operadores e funções espaciais, ainda não foi certificado como OpenGIS compliant. Agora, com a versão 1.0.0, lançada em 20 de abril de 2005, o PostGIS será submetido aos testes de conformidade à especificação OGC SFS, além de suportar geometrias 4D, novas funções e várias melhorias de desempenho. 4.2.2. Servidores de Mapas e Dados (WMS e WFS) 4.2.2.1. MapServer O MapServer [11][21] é um ambiente de desenvolvimento open source para aplicações espaciais baseadas em Internet. É baseado em outros sistemas open source como Shapelib, FreeType, Proj.4, GDAL e LibTIFF. Como conseqüência, grande parte das características oferecidas pelo MapServer na verdade são serviços providos por
outros sistemas e bibliotecas. Possui uma API em C e uma linguagem chamada MapScript que permite interação com linguagens como TCL, Perl, Python e Java. Há também módulos PHP/MapServer e Perl/MapServer, além da possibilidade de desenvolver aplicações através de JavaScript. A comunidade de software livre também participa ativamente do desenvolvimento do MapServer, além de desenvolver ferramentas para auxiliar na construção de softwares baseados em MapServer A CGI-BIN MapServer, de acordo com as bibliotecas opcionais incorporadas, oferece suporte a: formatos vector como ESRI shapefiles e ESRI ArcSDE; formatos raster como TIFF/GeoTIFF, GIF, PNG, ERDAS, JPEG e EPPL7; indexação espacial através de Quadtree; construção de mapas temáticos utilizando expressões lógicas ou regulares; consultas a bancos de dados como Oracle e sua extensão Oracle Spatial e PostgreSQL com sua extensão PostGis; protocolos OGC WMS (cliente/servidor)[3], WFS (cliente/servidor) não transacional[5], WCS (servidor)[6], WMC[12], SLD[2], GML, Filter Encoding[4], SFS (com PostGIS)[7]; e suporte a dimensão temporal em WMS[3]. Em geral, o MapServer é executado como uma aplicação CGI de um servidor HTTP. Entretanto, em aplicações mais avançadas, pode-se utilizar o MapScript para acessar a API do MapServer diretamente. O seu uso se baseia em uma fonte de dados, em um ou mais arquivos map (mapfile). Os arquivos map possuem uma sintaxe onde se definem as layers, formatação, labels, incorporação de imagens raster, dentre outras características, hierarquicamente organizados. Em resumo, os arquivos map dizem para o MapServer como exibir os dados da fonte.
4.2.2.2. MapServer como Servidor WMS O programa CGI do MapServer pode atuar como servidor WMS. Entretanto isso não é válido para todas as versões ou compilações. Isso pode ser verificado com a chamada ao programa com o parâmetro adequado, que lista as funcionalidades suportadas. Se desta lista existir a expressão SUPPORTS=WMS_SERVER, o programa pode atuar como servidor WMS. Este servidor necessita de um arquivo map da mesma forma que o MapServer convencional, mas com alguns dados e meta-dados obrigatórios. 4.2.2.3. MapServer como Servidor WFS Da mesma forma que o servidor WMS, o programa CGI do MapServ pode atuar como servidor WFS. Verificando as funcionalidades suportadas como na seção anterior, a expressão SUPPORTS=WFS_SERVER deve aparecer. Em relação ao mapfile, alguns parâmetros são obrigatórios, principalmente os que definem metadados. A Figura 7 apresenta uma combinação do MapServer WFS e do MarServer WMS. MapServer WFS MapServer WMS Shape Oracle Postgis ArcSDE OGR Raster Internet WMS REMOTE WFS REMOTE Figura 7 - WMS e WMS MapServer[19]
Toda a documentação existente é baseada em listas de discussão, HOWTOs e tutoriais existentes na página do MapServer. Embora a documentação seja bem abrangente, está espalhada em vários arquivos distintos, o que dificulta seu uso por um leigo. Os pontos positivos são que o processo de compilação, instalação, e os tutoriais são bem descritos e a comunidade de usuários responde prontamente a quaisquer dúvidas. 4.2.2.4. Geoserver Geoserver [23] é uma implementação Java da especificação OGC WFS com suporte completo a transações e um WMS integrado, permitindo que dados sejam recuperados tanto no formato GML (através do WFS) como em imagens (através do WMS). Utiliza a biblioteca Geotools para implementação das interfaces definidas pelo OGC, como por exemplo bibliotecas para representação de features, feature type, filtros, estilo em SLD e acesso a diversas fontes de dados, conforme ilustrado na Figura 8. Geoserver Geotools API Figura 8 - Bibliotecas Getools para acesso aos dados 4.2.2.5. Geoserver WFS Suporta dados do tipo Postgre/PostGIS, Shapefile, Oracle Spatial, ArcSDE, MySQL e WFS Remoto, além de todos os operadores espaciais para base de dados Oracle Spatial e Postgres.
4.2.2.6. Geoserver WMS O Geoserver WMS foi desenvolvido como uma opção para disponibilizar os dados do servidor WFS de forma gráfica. Sua arquitetura é definida e apresentada na Figura 9. Geoserver WFS Geoserver WMS Shape Oracle Postgis MySQL ArcSDE Internet GML WFS REMOTE Figura 9 - Arquitetura de Geoserver e suas fontes de dados 4.2.2.7. Deegree A arquitetura é totalmente baseada nos padrões OGC [17] : dados e metainformação dos objetos representados como feature e feature_type (GML, WFS), geometrias no padrão SFS e estilos no padrão SLD. As bibliotecas externas JTS e Batik são utilizadas, respectivamente, para representação da geometria e processamento de mapas no formato SVG. 4.2.2.8. Deegree WFS Trabalha com formatos de dados de entrada: Oracle, Postgres/Postgis, MySQL (com extensão espacial), SDE (ESRI), objetos do tipo ponto armazenados em bancos convencionais (geometria colunas X/Y), objetos com parte espacial representada em GML em bancos convencionais, Shapefiles e MapInfo (MIF). Possui flexibilidade para a definição das features types: as features types são configuradas definindo-se o esquema GML e um arquivo XML de mapeamento entre o
esquema GML e esquema de armazenamento. Neste arquivo de mapeamento é possível configurar: nomes das feature types e suas propriedades, feature type com dados em mais de uma tabela. 4.2.2.9. Deegree WMS O Deegree WMS utiliza como fonte de dados os serviços dos componentes Deegree WFS e Deegree WCS. O Deegree WMS não acessa a base de dados diretamente. A Figura 10 apresenta a arquitetura do framework. O servidor WMS pode obter dados de WFS e WCS locais, localizados na mesma maquina virtual, ou de WFS, WCS e WMS remotos. Sua arquitetura é detalhada na Figura 10. Deegree WFS Deegree WMS X /Y Oracle Postgis MySQL ArcSDE GML Shape Internet MIF WMS REMOTE WFS REMOTE WCS REMOTE GML Figura 10 - Arquitetura Deegree WMS 4.2.3. Clientes 4.2.3.1. MapServer Cliente O MapServer, além de poder ser configurado como servidor WMS e WFS, pode também ser configurado com um cliente WFS e/ou WMS. Por esta razão foi incluído nesta seção, embora não exista uma interface já construída como é o caso do JUMP. Embora várias funcionalidades estejam disponíveis, elas devem ser implementadas, mesmo que em um cliente simples HTML, e previamente configuradas
através de um arquivo map. No site do MapServer há um tutorial que explica passo a passo a construção de sistemas simples usando esta abordagem. 4.2.3.2. igeoportal igeoportal [26] é um cliente mapas no padrão cliente WMS. O principal ponto positivo do igeoportal é o fato de ele possuir uma arquitetura componentizada, baseada no conceito de módulos, compostos por arquivos HTML e JavaScript. Isso permite que o cliente de mapas seja expandido e adequado de acordo com as necessidades de um projeto específico. A arquitetura foi projetada desde do início utilizando padrões OGC. A configuração do mapa segue o padrão Context. Outro aspecto interessante é o fato dele ter sido projetado desde o início tendo em vista a questão da interoperabilidade (que é alcançada através da adoção dos padrões OGC). Com isso, é possível acessar, através do igeoportal, qualquer servidor de mapas que implemente os protocolos do padrão WMS. 4.2.3.3. udig Udig [14], User-friendly Desktop Internet GIS, é um framework Java para desenvolvimento de aplicações SIG desktop. A plataforma do udig é baseada na Eclipse Rich Client Platform (RCP), a qual utiliza conceitos de plug-ins. Desta forma, permite que novos módulos e funcionalidades sejam facilmente incorporados na arquitetura base. A plataforma udig é definida sobre o conceito de plug-ins incorporados a base do Eclipse Rich Client Platform. A arquitetura em três camadas pode é mostrada na Figura 11.
Figura 11 - Arquitetura Udig 4.2.3.4. JUMP JUMP [24], Unified Mapping Platform, é um framework Java desenvolvimento de aplicações desktop de visualização e manipulação de dados espaciais. Arquitetura é dividida em duas partes principais JUMP API e JUMP Workbench (GUI), conforme mostrado na Figura 12. Figura 12 - Arquitetura JUMP JUMP API possui um conjunto de APIs para representação de features, entrada e saída de dados e funcionalidades espaciais fundamentais. Geometrias são representados utilizando-se a biblioteca JTS, que implementada modelo espacial OGC SFS. JUMP Workbench fornece interface gráfica de acesso às funcionalidades disponibilizadas pelas APIs. Novos módulos podem implementados utilizando as APIs disponíveis e incorporados à solução utilizando o Plugin Framework.
4.2.4. Bibliotecas 4.2.4.1. Geotools Geotools [23] é um conjunto de APIs Java que pode ser utilizado para o desenvolvimento de soluções SIG em conformidade com o padrão OGC. Não é objetivo do projeto Geotools desenvolver aplicações, como por exemplo servidores WMS e WFS ou cliente Mapas, e sim disponibilizar bibliotecas que possam ser utilizadas para este fim. A arquitetura é modularizada o que permite que novas funcionalidades sejam facilmente incorporadas as bibliotecas. Além dessas bibliotecas, também foram desenvolvidos outros componentes que podem ser utilizados em soluções SIG: análise em redes, manipulação de grid e imagens e componentes para criação de uma aplicação SIG (applet). 4.2.4.2. JTS JTS Topology Suite [25] é uma API Java que implementa o modelo geométrico para objetos espaciais definido na especificação Simple Features Specification for SQL e funções espaciais sobre este modelo. Muitas funções espaciais já estão implementas: intersecção, diferença, união, buffer, convex hull, calculo de área e distância, validação topológica. JTS é uma biblioteca robusta que pode ser utilizada no desenvolvimento de outras aplicações espaciais como. Uma série de outros projetos opensource fazem uso desta biblioteca, entre eles estão Geotools, udig, Geoserver, Deegree e JUMP. 4.2.4.3. TerraLib O TerraLib [13] é uma biblioteca de classes e funções para SIG, desenvolvidas pelo INPE (Instituto Nacional de Pesquisas Espaciais), PUC-Rio e FUNCATE. Dentre outras características, permite a espacialização de bancos de dados que não suportam nativamente dados espaciais ou a extensão das capacidades espaciais de SGBDs como
MySQL, PostgreSQL e Oracle, através da definição de um modelo de dados geográficos e um conjuntos de funções externas ao SGBD. As funções englobam algoritmos de estatística espacial, processamento de imagens, projeções cartográficas, dentre outros. As funções são escritas em ANSI C++ e buscam implementar os últimos avanços da tecnologia de SIG. A compilação pode ser feita em ambiente Windows, usando Microsoft Visual C++ 6 ou.net, ou em Linux, com gcc versão 3.2.3 ou superior. A biblioteca e o modelo de dados empregado está passando por um grande esforço de documentação, visando melhorar seu uso por programadores que queiram iniciar no uso da ferramenta. A biblioteca está disponível sob licença LGPL, tanto para fins comerciais quanto para uso comercial. 5. Conclusão Há tempos o software livre deixou de ser uma possibilidade e tornou-se uma realidade. Atualmente ele já é usado em diversos sistemas críticos, e a evolução dos softwares gerados com licenças do tipo open source e free software tem sido notoriamente veloz. Muito mais que uma mudança de paradigma no mundo do software, o SL toca também em aspectos éticos e sociais, alterando, pois, o relacionamento da sociedade com o mundo de TI. A definição de padrões abertos para SIG, principalmente pelo OpenGeospatial Consortium (OGC), tem possibilitado não apenas a interoperabilidade entre sistemas, no sentido de comunicação e troca de dados, mas também a definição de arquiteturas SIG baseadas em componentes. E é neste aspecto que a combinação software livre e padrões abertos se torna muito atraente para toda comunidade SIG. Ela impulsiona o trabalho tanto da comunidade de Software Livre como do
OGC: o OGC busca a comprovação prática de suas especificações, a comunidade de Software Livre precisa de padrões que viabilizem o desenvolvimento baseado em componentes. Neste cenário fértil, acrescenta-se ainda a vantagem da portatabilidade, já que Java foi eleita como a linguagem de programação da grande maioria dos desenvolvedores da comunidade de Software Livre. A administração pública tem muito a ganhar com o SL e padrões internacionais abertos pelas várias razões já citadas - como redução de gastos com licenças de software - e possível aplicação do recurso em áreas prioritárias, não-aprisionamento a um único fornecedor, interrupção da obsolescência programada, dentre outros. Empresas de desenvolvimento de soluções SIG ganham agilidade no processo de implementação e flexibilidade para decidirem onde utilizar software livre e quais produtos (proprietários ou não) comporão sua solução. Em suma, o software livre e os padrões abertos internacionais tem conseguido atingir seu objetivo e cidadãos de todo mundo têm se beneficiado com a liberdade de escolha e compartilhamento da informação promovidos por eles. 6. Referências [1] Open Geospatial Consortium Inc. Disponível em http://www.opengeospatial.org. Acessado em 22 de abril de 2005. [2] Styled Layer Descriptor Implementation Specification - versão 1.0.0 - Documento n o : OGC 02-070. Open Geospatial Consortium Inc. [3] Web Map Service Implementation Specification - Documento n o : OGC 04-024. Open Geospatial Consortium Inc. [4] Filter Encoding Implementation Specification - Documento n o : OGC 02-059. Open Geospatial Consortium Inc. [5] Web Feature Service Implementation Specification - Documento n o : OGC 02-058. Open
Geospatial Consortium Inc. Acessado em 24 de abril de 2005 [6] Web Coverage Service - Documento n o : OGC 03-065r6. Open Geospatial Consortium Inc. Acessado em 24 de abril de 2005. [7] Simple Features SQL (SFS) Documento n o OGC 99-049. Open Geospatial Consortium Inc. Acessado em 24 de abril de 2005. [8] MySQL. Disponível em: http://www.mysql.org/. Acessado em 24 de abril de 2005. [9] PostgreSQL. Disponível em: http://www.postgresql.org/. Acessado em 24 de abril de 2005. [10] PostGIS. Disponível em: http://www.postgis.org/. Acessado em 24 de abril de 2005. [11] MapServer. Disponível em: http://mapserver.gis.umn.edu/. Acessado em 24 de abril de 2005. [12] Web Map Context Documents Implementation Specification versão 1.0.0 - Documento no: OGC 0-036r2. Open Geospatial Consortium Inc. Acessado em 24 de abril de 2005 [13] TerraLib. Disponível em: http://www.terralib.org/. Acessado em 24 de abril de 2005. [14] udig. Disponível em: http://udig.refractions.net/confluence/display/udig/home. Acessado em 24 de abril de 2005. [15] Daher, Alex Martins; Estudo de Infra-Estrutura de Software Livre Básico: SGBDS Com Suporte a Informações Espaciais. PD301168A0025A-RT03AA. Campinas, CPqD, 12/04/04. [16] Daher, Alex Martins. Estudo de Software Livre e suas Licenças. PD301168A0025A- RT16AA. Campinas, CPqD, Novembro/2004. [17] Teixeira, Marta Duarte; Gatti, Sandro Danilo; Mandolesi, Gustavo Henrique; Inagaki, Nelson; Estudo de Infra-Estrutura de Software Livre Básico: Proposta de uma Arquitetura GIS. PD301168A0025A-RT10AA. Campinas, CPqD, maio/04. [18] Daher, Alex Martins. Estudo da especificação OGC Simple Feature for SQL. Novembro/2004. [19] Mandolesi, Gustavo. WFS e WMS Aspectos técnicos. PD301168A0036A-RT02AA. Campinas, CPqD, Dezembro/2004.
[20] Oliveira, Carlos Machado. Padrão OGC: SLD Styled Layer Descriptor. PD301168A0036A-RT04AA. Campinas, CPqD, Março/2005. [21] Oliveira, Carlos Machado; Gatti, Sandro Danilo. Estudo de SIG para Web: MapServer. Campinas, CPqD, Janeiro/2005. [22] Oliveros, Dário Luís Coneglian; Estudo de Infra-Estrutura de Software Livre Básico, PD301168A0025A-RT02AA, Campinas, CPqD, Abril/04. [23] Teixeira, Marta Duarte; Estudo de SIG para Web - Geotools, Geoserver, Geoclient, Deegree Client. PD301168A0025A-RT04AA, Campinas, CPqD, Abril/04. [24] JUMP Unified Mapping Platform. Disponível em: http://www.vividsolutions.com/jump/. Acessado em 01 de junho de 2005. [25] JTS Topology Suite. Disponível em: http://www.vividsolutions.com/jts/. Acessado em 01 de junho de 2005. [26] deegree igeoportal. Disponível em:http://deegree.sourceforge.net/src/demos.html#client. Acessado em 01 de junho de 2005.