GeoServer, PostGIS, WMS e WFS: publicar as suas tabelas passo a passo

O princípio: uma tabela, uma camada, dois serviços

O PostGIS guarda as geometrias em tabelas PostgreSQL. O GeoServer liga-se a elas através de um armazém (store) e expõe cada tabela escolhida como uma camada. Essa camada é servida ao mesmo tempo em WMS, que devolve uma imagem desenhada com um estilo, e em WFS, que devolve as próprias entidades com os seus atributos.

A vantagem do PostGIS como fonte: a camada reflete a base em direto. Uma linha acrescentada ou corrigida na tabela aparece no serviço no pedido seguinte, sem voltar a publicar. É por isso que a combinação GeoServer, PostGIS, WMS e WFS é tão comum nas infraestruturas de dados espaciais.

Quando escolher um ou outro? O WMS serve para visualizar: o cliente recebe uma imagem leve, seja qual for o número de entidades, e o estilo é o mesmo para todos. O WFS serve para analisar e reutilizar: o cliente recebe geometrias e atributos, pode filtrar, calcular, exportar e até editar se a edição estiver aberta. Na prática, publica-se muitas vezes a mesma camada nos dois serviços, e cada utilizador escolhe conforme o uso.

Preparar a tabela PostGIS

Algumas precauções na base evitam a maioria dos erros de publicação: Depois de uma importação em massa, execute também VACUUM ANALYZE sobre a tabela: o PostgreSQL atualiza as estatísticas e escolhe então o plano de consulta certo, incluindo o índice espacial.

• Uma chave primária. Sem ela, o GeoServer não consegue identificar as entidades de forma estável e a edição por WFS-T torna-se impossível.
• Uma coluna geométrica tipada, com um sistema de coordenadas (SRID) declarado, por exemplo geometry(MultiPolygon, 4326) ou a projeção nacional.
• Um índice espacial na geometria, indispensável a partir de alguns milhares de entidades.
• Nomes simples: minúsculas, sem espaços nem acentos, para a tabela e as colunas.
• Um utilizador de leitura dedicado sempre que possível, em vez do proprietário da base.

CREATE INDEX parcelles_geom_idx ON parcelles USING GIST (geom);
SELECT Find_SRID('public', 'parcelles', 'geom');

Criar o armazém PostGIS no GeoServer

Na consola do GeoServer, um armazém PostGIS pertence a um espaço de trabalho. O procedimento habitual:

1. Criar ou escolher o espaço de trabalho que vai agrupar as camadas.
2. Adicionar um novo armazém do tipo PostGIS.
3. Indicar o anfitrião, a porta, a base, o esquema, o utilizador e a palavra-passe.
4. Guardar: o GeoServer testa a ligação e lista as tabelas disponíveis.

No GeoServer Cloud, a base PostGIS de uma instância LizPack Map liga-se ao seu espaço com um clique, sem formulário de ligação. As bases PostgreSQL e PostGIS dedicadas funcionam com PostgreSQL 17 e PostGIS 3.5, com ligação cifrada.

O formulário do armazém oferece também parâmetros de ligação muitas vezes esquecidos: o número máximo de ligações abertas à base, a validação das ligações antes do uso (útil quando a base reinicia de noite) e a exposição das chaves primárias, necessária se quiser filtrar ou editar pelo identificador. Se publicar vários esquemas, crie um armazém por esquema: as permissões e os nomes das camadas continuam legíveis.

Publicar a camada e dar-lhe um estilo SLD

Na lista de tabelas do armazém, publique a que lhe interessa. Na página da camada: Aproveite esta página para preencher o título, o resumo e as palavras-chave da camada: aparecem no GetCapabilities e são o que os seus parceiros leem no software deles, antes mesmo de apresentar o mapa. Um nome técnico como parcelles_v2 não diz nada; um título claro e um resumo datado evitam muitas perguntas.

1. Verificar o sistema de coordenadas declarado e o nativo.
2. Calcular as extensões a partir dos dados (nativa e depois em latitude e longitude).
3. No separador de publicação, escolher o estilo predefinido.
4. Guardar e verificar a pré-visualização da camada.

O estilo é um ficheiro SLD (Styled Layer Descriptor). Pode escrevê-lo à mão, partir de um modelo da consola ou exportá-lo a partir do QGIS (propriedades da camada, simbologia, guardar estilo como SLD). Um estilo mínimo para polígonos:

<PolygonSymbolizer>
  <Fill><CssParameter name="fill">#2F7A3E</CssParameter></Fill>
  <Stroke><CssParameter name="stroke">#083D44</CssParameter></Stroke>
</PolygonSymbolizer>

Sistemas de coordenadas: as armadilhas mais frequentes

O GeoServer distingue o sistema nativo, aquele em que a tabela está guardada, do sistema declarado, aquele que anuncia aos clientes. Na maioria dos casos são o mesmo e correspondem ao SRID da coluna geométrica. Quando o PostGIS não conhece o SRID (coluna declarada apenas como geometry, ou SRID igual a 0), o GeoServer não consegue adivinhar a projeção: a camada aparece no sítio errado, ou nem aparece. A correção certa faz-se na base, declarando o SRID correto, em vez de forçar uma projeção no GeoServer.

• Reprojeção em tempo real. Um cliente pode pedir a camada noutro sistema que não o de armazenamento, por exemplo EPSG:3857 para um mapa web. O GeoServer reprojeta cada pedido: é prático, mas custa cálculo nas camadas grandes. Se todos os seus mapas web trabalham em EPSG:3857, uma tabela ou vista já projetada acelera a representação.
• Ordem dos eixos em WFS. Com EPSG:4326, as versões 1.1.0 e 2.0.0 do WFS devolvem as coordenadas na ordem latitude e depois longitude, ao passo que a versão 1.0.0 e a maioria das ferramentas web esperam longitude e depois latitude. Pontos que aparecem trocados, no meio do oceano, vêm quase sempre daqui. Peça a versão do serviço adequada ao seu cliente, ou um sistema projetado.
• Lista de sistemas anunciados. Por predefinição, o documento GetCapabilities do WMS pode anunciar milhares de sistemas de coordenadas, o que o torna pesado e abranda alguns clientes. Os parâmetros do serviço WMS permitem limitar essa lista aos poucos sistemas que os seus utilizadores usam de facto.
• Extensões recalculadas. Depois de uma reprojeção ou de um carregamento grande de dados fora da antiga zona, recalcule as extensões da camada: caso contrário, os clientes aproximam-se de uma zona demasiado pequena ou ignoram parte das entidades.

Uma regra simples evita a maioria destes problemas: guarde os seus dados na projeção oficial do seu país ou território, declare-a corretamente no PostGIS e deixe o GeoServer reprojetar para os usos web. Mantém medições de distância e área corretas na base, e mapas web compatíveis com os mapas de base habituais.

Os endereços dos serviços WMS e WFS

O GeoServer expõe cada serviço num endereço próprio, normalmente limitado a um espaço de trabalho. O documento GetCapabilities descreve as camadas disponíveis; é ele que os clientes leem.

No GeoServer Cloud, cada serviço tem o seu endereço próprio no seu espaço. Para WFS, convém limitar o número de entidades devolvidas por pedido se a tabela for grande.

Consultar os serviços: filtros e formatos

Depois de publicada a camada, os clientes não se limitam a apresentá-la: consultam-na. Conhecer a forma dos pedidos ajuda a documentar os seus serviços para programadores e a diagnosticar o que um software pede realmente. Eis um pedido WFS 2.0 que devolve no máximo cinquenta parcelas de um concelho, em GeoJSON:

https://exemplo.org/geoserver/meuespaco/wfs?service=WFS&version=2.0.0
  &request=GetFeature&typeNames=meuespaco:parcelles
  &count=50&outputFormat=application/json
  &CQL_FILTER=commune='Dakar'

• typeNames designa a camada, com o prefixo do espaço de trabalho; em WFS 1.x o parâmetro chama-se typeName.
• count limita o número de entidades em WFS 2.0; o equivalente em WFS 1.x é maxFeatures. Em conjunto com startIndex, permite paginar uma tabela grande.
• outputFormat escolhe o formato de saída: GML por predefinição, application/json para GeoJSON, mais fácil de usar em JavaScript.
• CQL_FILTER é um parâmetro próprio do GeoServer que aceita filtros legíveis, de atributos ou espaciais. Os filtros OGC em XML continuam a ser a via normalizada, reconhecida por todos os servidores.
• bbox restringe a resposta a uma extensão, o que o QGIS e as bibliotecas web fazem automaticamente ao deslocar o mapa.
• propertyName limita os atributos devolvidos, útil quando a tabela tem dezenas de colunas.

Do lado do WMS, o pedido GetFeatureInfo devolve os atributos da entidade clicada no mapa: é ele que o Lizmap, o QGIS ou o OpenLayers usam para mostrar uma ficha de informação. O seu conteúdo depende dos atributos publicados: se um campo não deve ser visto, retire-o da vista publicada em vez de contar com o cliente para o esconder.

Desempenho e boas práticas WMS e WFS

Uma camada que funciona com cem entidades pode afundar com um milhão. A maioria das lentidões vem da base ou da consulta, não do próprio GeoServer. Alguns ajustes fazem quase toda a diferença, e fazem-se uma vez, no momento da publicação.

• Publicar uma vista em vez de uma tabela em bruto. Uma vista PostgreSQL, ou uma vista SQL declarada no GeoServer, só devolve as colunas e linhas úteis: menos dados transferidos e menos risco de expor um campo interno.
• Limitar as entidades devolvidas pelo WFS. Defina um limite na configuração do serviço e peça aos clientes que filtrem por extensão ou por atributo em vez de descarregar tudo.
• Simplificar para escalas pequenas. À escala de um país, não é preciso enviar contornos ao metro: uma tabela simplificada, ou regras de escala no estilo SLD, aliviam a representação.
• Pôr em cache o que muda pouco. Os mapas de base e as camadas de referência ganham em ser servidos em WMTS a partir da cache de mosaicos integrada. Lembre-se de limpar a cache quando os dados mudam.
• Indexar as colunas filtradas. Se os utilizadores filtram por concelho ou por data, um índice nessas colunas conta tanto como o índice espacial.
• Enquadrar a edição WFS-T. A escrita online é poderosa, mas exige uma conta de base autorizada a escrever, permissões por camada no GeoServer e uma chave primária fiável.

Mantenha por fim uma regra simples de segurança: o utilizador PostgreSQL do armazém só deve ter os direitos de que a camada precisa. Um armazém só de leitura não pode alterar nada, mesmo que um serviço esteja mal configurado. Para as outras precauções, veja o guia proteger e atualizar o GeoServer.

Testar no QGIS

1. No QGIS, abrir o gestor de fontes de dados.
2. Separador WMS/WMTS: criar uma ligação com o endereço WMS, ligar e adicionar a camada. O estilo SLD deve aparecer.
3. Separador WFS: criar uma ligação com o endereço WFS, adicionar a camada e abrir a tabela de atributos para verificar os campos.
4. Alterar uma linha no PostGIS e atualizar o mapa: a alteração aparece.

Se a camada estiver vazia, verifique as extensões e o SRID; se estiver lenta, o índice espacial. Para alojar tudo sem servidor, veja o alojamento GeoServer online. Para escolher entre GeoServer e QGIS Server, leia a nossa comparação.

Erros frequentes e soluções

Os mesmos problemas repetem-se de projeto para projeto. A tabela seguinte parte do sintoma observado, no QGIS ou num navegador, para chegar à causa mais provável.

Quando o sintoma não consta desta tabela, veja primeiro a resposta em bruto do servidor: abra o endereço do pedido num navegador. O GeoServer devolve uma mensagem de exceção explícita (camada desconhecida, atributo inexistente, erro SQL) que os clientes cartográficos escondem muitas vezes atrás de um mapa vazio. Os registos do GeoServer e do PostgreSQL completam o diagnóstico, sobretudo para os erros SQL de uma vista mal escrita.

Perguntas frequentes