Padrões OGC na prática: WMS, WFS, WMTS e OGC API - Features

Existe um momento comum em projetos de geotecnologia: o time recebe um link terminado em ?service=WMS&request=GetCapabilities, cola no software GIS, o mapa aparece e todo mundo comemora. Duas semanas depois, alguém pergunta quantos imóveis estão dentro de determinado polígono, e a resposta é constrangedora: não dá, porque aquilo nunca foi dado, era um desenho.

Padrões OGC não são burocracia de especificação. Eles são a diferença entre um mapa que você olha e um dado que você usa. Este guia percorre os quatro padrões que você mais vai encontrar, com as definições oficiais de cada um, e termina no critério prático de escolha.

Por que existe um padrão para isso

A OGC, Open Geospatial Consortium, é a organização que publica as especificações de interoperabilidade adotadas por praticamente todo o mercado de software geoespacial. A justificativa aparece de forma direta na própria descrição do WMTS: o padrão "oferece uma abordagem padronizada para declarar as imagens que um cliente pode requisitar de um servidor, permitindo que um único tipo de cliente seja desenvolvido para todos os servidores".

É esse o ganho concreto. Sem padrão, cada órgão publicaria dados com um contrato de interface próprio, e cada cliente precisaria de um conector específico. Com padrão, o mesmo QGIS, o mesmo ArcGIS e o mesmo aplicativo de campo falam com centenas de servidores diferentes sem uma linha de código dedicada a cada um. Se você está escolhendo a plataforma GIS da operação, esse ponto pesa tanto quanto as funcionalidades internas, assunto que tratamos no comparativo entre ArcGIS e QGIS.

A pergunta que organiza tudo: imagem ou dado?

Antes de decorar siglas, vale fixar o eixo que separa os padrões em dois grupos.

• Serviços de imagem. O servidor renderiza o mapa e entrega pixels. O cliente exibe. WMS e WMTS estão aqui.
• Serviços de feição. O servidor entrega geometrias e atributos. O cliente calcula, filtra, cruza e, em alguns casos, escreve de volta. WFS e OGC API - Features estão aqui.

WMS: o mapa desenhado sob demanda

O Web Map Service é o padrão mais antigo e mais difundido dos quatro. A versão corrente é a 1.3.0, equivalente à norma ISO 19128. A OGC descreve que ele "fornece uma interface HTTP simples para requisitar imagens de mapa georreferenciadas de uma ou mais bases de dados geoespaciais distribuídas".

O funcionamento é o que a definição sugere: "uma requisição WMS define a camada ou camadas geográficas e a área de interesse a serem processadas. A resposta à requisição é uma ou mais imagens de mapa georreferenciadas (retornadas como JPEG, PNG, etc.) que podem ser exibidas em uma aplicação de navegador".

Um detalhe da especificação tem consequência prática grande: a interface "também suporta a capacidade de especificar se as imagens retornadas devem ser transparentes, de modo que camadas de múltiplos servidores possam ser combinadas". É isso que permite empilhar uma camada de unidades de conservação de um órgão sobre uma imagem de satélite de outro, dentro do mesmo projeto, sem que nenhum dos dois saiba da existência do outro.

O que o WMS não faz: ele não entrega a geometria. Você não recorta, não mede área, não roda análise espacial sobre um WMS. Para isso o dado precisa estar do seu lado, tipicamente em um banco como o PostGIS.

WMTS: o mapa recortado em tiles

O Web Map Tile Service, na versão 1.0.0, resolve um problema específico de escala. Em vez de renderizar cada requisição do zero, ele "fornece uma solução baseada em padrão para servir mapas digitais usando blocos de imagem predefinidos". A OGC é explícita ao dizer que o padrão "complementa o Web Map Service existente", ou seja, não veio para substituí-lo.

A troca é fácil de entender. O WMS é flexível e caro: cada combinação de área, camadas e estilo gera um desenho novo no servidor. O WMTS é rígido e barato: as imagens já existem, organizadas em uma grade de níveis de zoom, e o servidor apenas as devolve. Para uma camada de fundo consultada por milhares de usuários, essa rigidez é exatamente o que se quer.

A grade em si é objeto de outro padrão, o OGC Two Dimensional Tile Matrix Set, que define esquemas de tiles 2D para uso fora de um serviço de tiles. Vale conhecer o nome: quando dois serviços de tiles não se sobrepõem corretamente no seu projeto, o esquema de tiles costuma ser o primeiro suspeito.

WFS: a feição consultável

O Web Feature Service muda de natureza. Ele oferece, nas palavras da OGC, "acesso direto e granular à informação geográfica no nível da feição e da propriedade da feição". A versão publicada mais recente é a 2.0.2, que corresponde ao documento da interface WFS 2.0 com corrigendum.

O padrão especifica "operações de descoberta, operações de consulta, operações de travamento, operações de transação e operações para gerenciar expressões de consulta armazenadas e parametrizadas". Traduzindo para o uso cotidiano:

• Consulta. As operações de consulta "permitem que feições ou valores de propriedades de feições sejam recuperados do armazenamento subjacente com base em restrições, definidas pelo cliente, sobre as propriedades das feições". É o filtro do lado do servidor: você pede apenas os lotes de um bairro, não a cidade inteira.
• Transação. As operações de transação "permitem que feições sejam criadas, alteradas, substituídas e excluídas do armazenamento subjacente". É o chamado WFS-T, base de fluxos de edição colaborativa.
• Travamento. Existe para que duas pessoas não editem a mesma feição ao mesmo tempo sem perceber.

Há um ponto de status que precisa ser dito com clareza, porque afeta decisão de arquitetura. A OGC registra que o WFS "continua sendo um meio confiável de fornecer dados geoespaciais para a web", mas acrescenta que "suas capacidades funcionais estão agora disponíveis em uma API web mais moderna, OGC API - Features, e implementadores são incentivados a usar o padrão mais novo".

OGC API - Features: a geração web

A OGC API - Features é descrita como "um padrão multipartes que oferece a capacidade de criar, modificar e consultar dados espaciais na web". A diferença de fundo em relação ao WFS não é de capacidade, é de forma: em vez de parâmetros de requisição empilhados em uma única URL de serviço, os dados viram recursos web endereçáveis, com JSON e HTML como cidadãos de primeira classe, descritos por OpenAPI.

A organização em partes vale ser conhecida antes de contratar ou publicar um serviço, porque nem todo servidor implementa tudo. Na data desta publicação, o quadro é o seguinte:

Os caminhos são previsíveis o suficiente para serem explorados no navegador. O recurso /collections "lista as coleções de dados no servidor que podem ser consultadas", com identificador, descrição e extensões espacial e temporal. O recurso /collections/{collectionId}/items devolve os dados da coleção, e a especificação registra que "os dados são retornados em blocos pagináveis, com cada resposta contendo um link next". Já /collections/{collectionId}/items/{featureId} "retorna uma única feição", algo do mundo real como uma edificação, um curso d'água ou um município, em uma URL estável.

Sobre formato, a documentação da OGC aponta que a resposta é "tipicamente HTML ou uma coleção de feições GeoJSON, mas GML também é suportado, e extensões podem facilmente fornecer outros", com a escolha feita por negociação de conteúdo do HTTP. O filtro espacial básico usa o parâmetro bbox, e a Parte 2 acrescenta os parâmetros crs e bbox-crs para tratamento de sistemas de referência.

Comparativo rápido

A tabela abaixo resume o critério de escolha. As duas primeiras colunas vêm das definições oficiais; a coluna de uso típico é a nossa recomendação prática, formada em projetos de integração.

Uma regra prática que costumamos aplicar: se o serviço vai alimentar um sistema que decide algo, e não apenas ilustrar uma tela, comece pela feição. É mais trabalhoso no início e evita a reescrita quando alguém pedir o primeiro cruzamento espacial.

Onde isso aparece no Brasil

Esses padrões não são exercício acadêmico: eles são o meio pelo qual boa parte do dado público brasileiro chega à sua operação. A Infraestrutura Nacional de Dados Espaciais, a INDE, é descrita pelo portal oficial como um "conjunto integrado de tecnologias, políticas, mecanismos e procedimentos" voltado à geração, ao armazenamento, ao acesso e ao compartilhamento de dados geoespaciais, concebida "com o propósito de catalogar, integrar e harmonizar dados geoespaciais produzidos" por órgãos das esferas federal, estadual e municipal.

Entre os instrumentos que o portal disponibiliza estão um visualizador de mapas, um catálogo de metadados e um catálogo de geoserviços. Esse último é o ponto de contato direto com o tema deste artigo: é ali que estão publicados os endereços dos serviços que um cliente GIS consome. Para quem trabalha com dados territoriais no setor público, esse encadeamento entre metadado, geoserviço e uso operacional é o mesmo que sustenta o cadastro territorial multifinalitário.

Do lado do cliente, a cobertura é ampla. A documentação do QGIS registra suporte a "WFS 1.0.0, 1.1.0, 2.0 e OGC API - Features (OAPIF), incluindo edição (por meio de WFS-T)", além de WMS, WMTS e WCS. Dois comportamentos documentados ali merecem atenção de quem opera:

• Cache de WMS. O QGIS "armazenará em cache suas respostas WMS (isto é, imagens) por 24 horas, desde que a requisição GetCapabilities não seja disparada". Isso acelera a abertura do projeto e, ao mesmo tempo, explica por que uma camada atualizada no servidor pode continuar aparecendo velha na sua tela.
• Edição por OGC API - Features. Camadas de servidores que implementam a Parte 4 podem ser editadas, mas a documentação alerta que "cada feição criada, modificada ou excluída exige uma requisição de rede dedicada, então o desempenho pode sofrer" em edições simultâneas de grande volume.

Sete armadilhas de quem consome geoserviço

A lista a seguir é a nossa leitura, acumulada em projetos de integração de dados territoriais. Não é afirmação das fontes citadas.

1. Tratar WMS como fonte de verdade. Imagem não tem atributo. Se o número precisa entrar em relatório, ele não pode vir de um serviço de imagem.
2. Ignorar o GetCapabilities. É o documento que diz quais camadas, quais projeções e quais formatos o servidor aceita. Ler antes economiza horas de tentativa e erro.
3. Puxar a coleção inteira. O filtro do lado do servidor existe justamente para isso. Baixar tudo e filtrar depois funciona no piloto e cai em produção.
4. Esquecer a paginação. Em OGC API - Features, a resposta vem em blocos com link next. Um cliente que lê só a primeira página produz um relatório silenciosamente incompleto.
5. Não fixar o sistema de referência. Combinar camadas em projeções diferentes gera deslocamento que ninguém percebe até virar erro de campo. Vale revisar os fundamentos em nosso guia de geoprocessamento.
6. Confiar no cache sem saber que ele existe. O comportamento de cache do cliente é documentado, mas raramente lembrado na hora de conferir se o dado está atualizado.
7. Depender de serviço externo em campo. Equipe em rua com conectividade instável precisa de dado embarcado ou sincronizado, e não de uma chamada ao vivo a um servidor de terceiro. É um dos motivos pelos quais o Phrisma trabalha com base local sincronizada em vez de consulta remota a cada operação.

Padrão aberto resolve o transporte do dado. Ele não resolve a qualidade, a atualização nem o encaixe daquele dado no seu processo, e é aí que a maior parte do trabalho realmente está. Se o seu desafio é integrar geoserviços de várias origens em um fluxo operacional único, os produtos da Felikis mostram como montamos esse desenho ponta a ponta.

Perguntas frequentes

Fontes e referências