Nos dias de hoje, as corporações estão em busca cada vez mais de ferramentas eficientes para o apoio a tomada de decisão. Em um mundo competitivo e com excesso de informações em que vivemos, quem tem acesso a informações estratégicas consolidadas leva vantagem em relação aos seus concorrentes. Devido a isso o mundo corporativo vem olhando já a algum tempo com outros olhos para as informações geográficas integradas as informações de negócio.
Os executivos não têm mais tempo para ficar vendo relatórios com inúmeras páginas, eles precisam de ferramentas que lhes apresente de uma forma rápida e resumida o que está acontecendo, ou que caminho ele deve seguir, e as aplicações com mapas dão esse retorno imediato e visual que eles tanto procuram.
Mas, é claro, que como em qualquer corporação, os executivos querem que o custo para a aquisição dessas soluções sejam o menor possível, e para que isso ocorra e que você consiga ter uma ferramenta competitiva uma das alternativas é adotar uma arquitetura 100% open source.
Neste artigo, irei apresentar uma sugestão de arquitetura, e dar algumas dicas para você que quer desenvolver seu WebGIS.
1. A arquitetura
A arquitetura representada pela figura abaixo, será detalhada nos próximos itens deste artigo.
Figura 1. Arquitetura Open Source GIS
2. Banco da dados
Para base da nossa arquitetura, é preciso definir qual será o repositório de dados. A sugestão aqui é o PostGIS, a extensão geográfica do banco de dados relacional PostgreSQL.
O PostGIS é um projeto que nasceu em 2001 pela Refractions Research, e adquiriu maturidade e confiabilidade no decorrer dos anos, sendo que hoje é utilizado por instituições governamentais, bancárias, dentre outras.
É importante ressaltar que ele é a implementação de referência do padrão SFS da OGC, que define como deve ser realizado o armazenamento da informação geográfica.
Figura 2. Dados geográficos sendo visualizados através do PgAdmin
3. Application Server
O servidor de aplicações é a peça da arquitetura que faz a ligação entre o banco de dados e os clientes (web e desktop). Ele será o camisa 10 do seu time (analogia ao futebol).
A minha sugestão é o GeoServer, pois ele por concepção tem o objetivo de interoperar as informações geográficas através dos padrões WMS, WFS, WCS, WPS, GML, etc.
Uma dica que posso dar é sobre o acesso ao repositório de dados, minha sugestão é que somente o GeoServer tenha acesso direto aos bancos de dados, e que as demais partes do sistema (Clientes), acessem as informações a partir do GeoServer através dos padrões OGC ou via API REST.
Figura 3. Interface web do GeoServer
Apesar da sugestão para o application server ter sido o GeoServer, você tem outras opções que podem se encaixar melhor na sua arquitetura como o MapServer ou o deegree, fique à vontade para escolher o que for melhor para seu projeto e arquitetura.
Na segunda parte do artigo falarei sobre gerenciador de cache, cliente Web e cliente Desktop.
Aguarde!
