GeoServer ou QGIS Server, ou MapServer: que servidor de mapas escolher

Em resumo

O QGIS Server serve um projeto QGIS tal como o construiu no QGIS Desktop, com os seus estilos, etiquetas e composições. O GeoServer publica camadas independentes de um projeto, com os seus próprios estilos SLD, e visa as infraestruturas de dados. O MapServer é o mais antigo, muito rápido, configurado através de um ficheiro de texto. O Martin e o pg_tileserv fazem uma só coisa: servir mosaicos vetoriais, sobretudo a partir do PostGIS.

Nenhum é melhor em absoluto. A escolha certa depende da sua ferramenta de trabalho, dos seus utilizadores e da equipa que vai manter o servidor.

Os servidores lado a lado

Todos estes programas são livres. As linguagens e funções indicadas são as dos respetivos projetos; consulte a documentação da versão que instalar.

Os estilos: onde os servidores mais diferem

No papel, todos estes servidores publicam WMS. Na prática, a diferença que mais se sente no dia a dia está na forma de descrever o aspeto dos mapas. É aí que se decidem o tempo de publicação, a qualidade da representação e a facilidade de manutenção.

• O QGIS Server lê diretamente o projeto QGIS: simbologia, etiquetas, regras de escala, modos de mistura, composições de impressão. O que vê no QGIS Desktop é o que o servidor desenha, porque ambos partilham as mesmas bibliotecas de representação.
• O GeoServer usa a norma SLD, um formato XML extenso mas normalizado. Extensões oficiais permitem também escrever os estilos em CSS ou em YSLD, mais legíveis. Um estilo do QGIS pode ser exportado para SLD, mas as representações avançadas (efeitos, geradores de geometria, certas etiquetas) perdem-se muitas vezes pelo caminho.
• O MapServer descreve os estilos no mapfile, com blocos CLASS e STYLE e expressões que decidem a classe de cada entidade. Também sabe ler SLD. O formato é compacto e revê-se bem, mas escreve-se à mão.
• O Martin e o pg_tileserv não aplicam estilos: enviam geometrias, e o estilo é um documento JSON interpretado pela biblioteca cliente, por exemplo o MapLibre. Mudar uma cor não exige qualquer intervenção no servidor.

Consequência prática: se os seus mapas são ricos e já cuidados no QGIS, qualquer outro servidor vai pedir-lhe que traduza esses estilos e depois mantenha duas versões. Se as suas camadas são simples (preenchimentos, contornos, poucas classes), o formato pouco importa e outros critérios, como a cobertura de normas ou o desempenho, passam para primeiro plano. Teste três das suas camadas mais complexas antes de decidir: é a forma mais rápida de medir o esforço real.

GeoServer ou QGIS Server: a verdadeira questão

Para a maioria das equipas que trabalham no QGIS, a escolha joga-se entre estes dois. A pergunta decisiva: onde vivem os seus estilos?

• Os seus mapas são concebidos no QGIS e devem aparecer na web exatamente como no ecrã: QGIS Server, com o Lizmap por cima para obter um portal completo (pesquisa, edição, impressão).
• Difunde camadas a parceiros que as vão usar nas suas próprias ferramentas (ArcGIS, OpenLayers, catálogo de dados): GeoServer, concebido para publicar serviços OGC autónomos.
• Precisa dos dois: é frequente. Um portal Lizmap para os utilizadores, um GeoServer para os serviços de referência. Uma camada do GeoServer pode, aliás, ser adicionada a um projeto QGIS publicado no Lizmap como qualquer serviço WMS ou WFS.

Na LizPack, os dois funcionam lado a lado: o LizPack Map inclui o QGIS Server, e o GeoServer Cloud oferece um espaço GeoServer isolado que se liga à sua base PostGIS. Para o lado do Lizmap, veja alojar o Lizmap ou instalá-lo por conta própria. Um caso frequente ilustra a repartição: uma autarquia publica o seu plano diretor num portal Lizmap, com pesquisa por parcela, impressão em A3 e edição de pedidos pelos técnicos. Os mesmos zonamentos são publicados no GeoServer para o portal regional de dados, que os recolhe todas as noites. Uma única base PostGIS alimenta os dois, e uma correção feita de manhã aparece em todo o lado.

MapServer: a velocidade, à custa da configuração

O MapServer, nascido na Universidade do Minnesota e hoje projeto da fundação OSGeo, continua a ser uma referência para servir grandes volumes de mapas com poucos recursos. Tudo é descrito num mapfile, um ficheiro de texto que define camadas, fontes e estilos.

É uma excelente escolha para uma equipa técnica à vontade com ficheiros de configuração e controlo de versões. Para técnicos SIG que querem publicar a partir de uma interface, o GeoServer ou o QGIS Server serão mais acessíveis.

O MapServer não se limita ao modo servidor: as suas ligações MapScript permitem controlar a representação a partir de Python ou de outras linguagens, para gerar mapas em lote ou integrar o motor numa aplicação. O projeto, sob licença de tipo MIT, é mantido por um comité de direção no seio da fundação OSGeo.

Desempenho: o que realmente conta

As comparações de velocidade entre servidores circulam muito, mas raramente dizem grande coisa sobre o seu caso. Com dados reais, a diferença entre dois servidores bem configurados é muitas vezes menor do que a diferença entre uma camada bem preparada e uma mal preparada no mesmo servidor. Antes de culpar o software, verifique estas alavancas, válidas para todos:

• A cache de mosaicos. O GeoServer integra o GeoWebCache; o MapServer é muitas vezes acompanhado do MapCache; à frente do QGIS Server, uma cache de mosaicos evita redesenhar as mesmas zonas. Um mapa consultado por muitos utilizadores deve quase sempre passar por uma cache.
• A fonte de dados. Uma tabela PostGIS indexada responde muito melhor do que um Shapefile grande ou um ficheiro lido a partir de um disco de rede lento.
• As regras de escala. Mostrar todas as parcelas de um país a pequena escala é dispendioso e ilegível; limite cada camada às escalas em que faz sentido.
• As etiquetas e os efeitos. As etiquetas com gestão de colisões, as sombras e os efeitos de camada custam caro. São muitas vezes eles, e não as geometrias, que tornam lento um projeto QGIS publicado.
• Os rasters. Um GeoTIFF em mosaico, comprimido e com vistas gerais lê-se muito mais depressa do que uma imagem em bruto com o mesmo conteúdo.

Para comparar com honestidade, meça o tempo de resposta do mesmo pedido GetMap, na mesma camada, com e sem cache, a duas ou três escalas. Guarde essas medições: servirão também para confirmar que uma atualização do servidor não piorou nada.

Martin e pg_tileserv: os mosaicos vetoriais

Os mosaicos vetoriais (formato MVT) enviam ao navegador geometrias recortadas, que a biblioteca cliente (MapLibre, OpenLayers) desenha ela própria. O resultado é fluido e o estilo muda sem mexer no servidor. Servem bem os mapas públicos muito consultados, os mapas de base personalizados e as aplicações móveis. Servem menos quando o utilizador tem de imprimir um mapa normalizado, consultar atributos completos ou obter exatamente a mesma representação em todos os programas.

• O Martin, projeto da comunidade MapLibre, serve mosaicos a partir de PostGIS, MBTiles ou PMTiles.
• O pg_tileserv, publicado pela Crunchy Data, expõe tabelas e funções PostGIS como mosaicos com muito pouca configuração.
• Nenhum substitui um WMS ou um WFS: complementam um servidor OGC para mapas web públicos.

Os dois servidores assentam na capacidade do PostGIS de produzir ele próprio mosaicos no formato MVT. Consequência prática: o desempenho depende sobretudo da base, dos seus índices e da complexidade das geometrias. O Martin também serve ficheiros GeoJSON e mosaicos já gerados, o que o torna uma boa escolha para combinar dados vivos e mapas de base estáticos.

O que exige a exploração de cada servidor

A escolha de um servidor compromete durante anos. Para além das funções, veja o que será preciso fazer todos os meses para o manter em serviço: quem sabe configurá-lo, como se atualiza e o que exige da máquina. Anote também quem, na sua equipa, será avisado de uma falha de segurança e saberá aplicar a correção na mesma semana: é muitas vezes o critério que desempata dois servidores com funções equivalentes.

Duas notas práticas. Primeiro, os servidores não se excluem: muitas organizações usam o QGIS Server para os portais e o GeoServer para os serviços de referência, sobre a mesma base PostGIS. Depois, o custo real é o tempo humano. Um servidor que ninguém na equipa sabe atualizar acaba por se tornar um risco, por melhor que seja. É esse o trabalho que a LizPack, uma infraestrutura geoespacial de código aberto, assume ao orquestrar estes programas sem os substituir: o que faz a LizPack detalha essa repartição.

Os erros frequentes na hora de escolher

• Escolher por uma lista de funções. Os quatro servidores cobrem as normas principais. O que faz a diferença é a sua cadeia de trabalho: onde nascem os mapas, quem os mantém, quem os consome.
• Subestimar a tradução dos estilos. Passar de um projeto QGIS cuidado para estilos SLD equivalentes pode levar dias por mapa. Esse custo tem de entrar na comparação.
• Esquecer os clientes. Um parceiro que espera WFS 2.0, um portal de dados que recolhe GetCapabilities, uma aplicação móvel que lê mosaicos vetoriais: parta do que eles sabem ler.
• Achar que um só servidor tem de fazer tudo. Um portal QGIS Server com Lizmap para os utilizadores e um GeoServer para os serviços de referência, sobre a mesma base PostGIS, é uma arquitetura comum e saudável.
• Descurar a manutenção. O melhor servidor torna-se um risco se nunca for atualizado. Escolha aquele que a sua equipa saberá realmente manter, ou delegue essa parte do trabalho.
• Testar com dados de brincar. Um teste com dez entidades não diz nada. Use as suas camadas reais, com os volumes reais e os seus estilos.

Um método simples funciona bem: ficar com dois candidatos, publicar as mesmas três camadas representativas em cada um, apresentá-las nos clientes dos seus utilizadores, medir e estimar o tempo de manutenção anual. Em uma ou duas semanas a resposta costuma ser clara, e assenta nos seus dados e não em reputações.

Escolher conforme a sua necessidade

Seja qual for o servidor, terá de ser mantido: Java ou bibliotecas do sistema, certificados, atualizações de segurança. O guia proteger e atualizar o GeoServer mostra o que isso implica na prática. Se mantiver o QGIS Server e o GeoServer lado a lado, use uma regra de nomes comum para as camadas e documente que camada é publicada onde: os utilizadores saberão que endereço usar, e evitará manter duas versões divergentes do mesmo dado.

Perguntas frequentes