WFS y OGC API Features no son sinónimos ni una migración automática. Los dos pueden publicar entidades geográficas para consulta, pero atienden ecosistemas y contratos técnicos distintos. La decisión correcta empieza por los consumidores reales, no por cuál sigla parece más actual.
El estándar WFS 2.0 sigue siendo una forma válida de dar acceso detallado a entidades y propiedades. La propia OGC señala que sus capacidades están disponibles en una API web más moderna y anima a considerar OGC API Features para nuevas implementaciones. Eso no convierte un WFS existente en un error ni autoriza apagarlo sin probar a sus clientes.
La consultoría de interoperabilidad geoespacial de GeoSAT puede inventariar servicios y diseñar esa transición. Antes de publicar, aplique también la auditoría de metadatos y GetCapabilities.
Qué cambia entre los dos enfoques
WFS define operaciones de descubrimiento, consulta y, en los perfiles que correspondan, bloqueo y transacción. Sus clientes suelen iniciar con GetCapabilities, consultar el tipo de entidad y pedir resultados mediante los parámetros definidos por el servicio.
OGC API Features organiza los recursos como una API web: una página de entrada, colecciones, elementos y, según el servidor, una definición OpenAPI y distintos formatos. La OGC lo describe como un estándar construido sobre prácticas web actuales, incluidas REST, OpenAPI, JSON y HTML.
La diferencia práctica no es que uno “tenga datos” y el otro no. Es cómo un consumidor descubre, entiende, consulta y mantiene el contrato del servicio.
| Si necesita principalmente… | Punto de partida razonable |
|---|---|
| Compatibilidad con flujos de escritorio o integraciones ya probadas contra WFS | Mantener WFS, documentarlo y corregir sus metadatos y límites. |
| Una API legible para aplicaciones web, equipos de desarrollo y documentación OpenAPI | Evaluar OGC API Features para las colecciones de lectura. |
| Edición compartida, bloqueo, validaciones y trazabilidad de cambios | Diseñar el flujo de edición de forma explícita; no asumir que la API de lectura lo resuelve. |
| Sustituir una plataforma heredada sin detener servicios críticos | Publicar en paralelo, probar consumidores y retirar solo lo que tenga reemplazo aceptado. |
Inventarie consumidores antes de mover una ruta
Un servicio puede alimentar QGIS, ArcGIS, un visor propio, una aplicación móvil, una hoja de cálculo automatizada o un proceso de integración que nadie recuerda. Para cada uno, registre:
- URL, versión, autenticación y responsable.
- Operación o ruta que usa y filtros habituales.
- Volumen, frecuencia y tiempo de respuesta que necesita.
- Formato, CRS, identificador estable y campos que no puede perder.
- Comportamiento esperado ante error, dato sin geometría o resultado vacío.
No todos los clientes interpretan paginación, filtros, proyecciones o formatos de la misma manera. Ese inventario convierte “migrar servicios” en casos que se pueden ejecutar y aprobar.
Decida qué se publica y bajo qué contrato
No todo lo que está en la base debe convertirse en una colección pública. Separe datos públicos, internos, restringidos y de intercambio controlado. Para cada colección publicada defina nombre estable, descripción, propietario, licencia, fecha de actualización, cobertura espacial y temporal cuando aplique, CRS disponibles, límites de consulta y política de cambios.
Documente los identificadores como parte del contrato. Si una entidad cambia de clave al pasar de WFS a una API, los enlaces, cachés, formularios y referencias externas pueden dejar de significar lo mismo aunque el mapa siga mostrando polígonos.
Migre con una prueba paralela
Una transición prudente suele seguir esta secuencia:
- Establezca una línea base. Guarde ejemplos de consultas, respuestas, conteos, atributos y geometrías de los flujos críticos.
- Publique una colección de prueba. Use un nombre de entorno visible y datos autorizados; no sustituya la URL productiva todavía.
- Compare resultados. Revise identificadores, filtros espaciales y por atributos, codificación, nulos, CRS, paginación y límites.
- Pruebe clientes reales. Incluya al menos los consumidores de mayor riesgo, no solo una llamada desde el navegador.
- Prepare reversión. Defina quién decide el cambio, cómo se restaura el servicio anterior y cómo se informa a quienes integran la fuente.
WFS y OGC API Features pueden convivir durante una transición. Mantener dos rutas es una decisión operativa con costo de pruebas, seguridad y documentación; no debería convertirse en duplicación indefinida sin responsable.
No confunda un endpoint con interoperabilidad
Un endpoint no es interoperable por el solo hecho de responder. El servicio debe explicar lo que publica y sostenerlo en el tiempo. Antes de aceptar una entrega, pruebe:
- Que una persona externa autorizada pueda descubrir y entender la colección.
- Que los filtros no permitan inferir o descargar información restringida.
- Que la respuesta identifique fuente, corte, licencia y límites de uso.
- Que haya trazas, métricas y alertas para errores de publicación o consultas anómalas.
- Que una actualización preserve o documente los cambios de esquema e identificadores.
Para una entidad colombiana, estas pruebas ayudan a aterrizar principios de catálogo, metadatos y servicios sin prometer una certificación por usar una sigla. La evidencia depende del conjunto de datos, los consumidores y el marco institucional aplicable.
Próximo paso
Si el WFS actual funciona, puede ser más valioso documentarlo y probar su recuperación que reemplazarlo por moda. Si un nuevo portal o producto necesita una API orientada a recursos, OGC API Features puede ser una base más natural. La elección puede incluir ambos durante un periodo controlado.
GeoSAT puede preparar el inventario, el contrato de publicación y las pruebas de transición. Luego conecte la decisión con una arquitectura de geoportal sostenible, donde el servicio es una capa operable y no la única copia del dato.
Fuentes y referencias
- OGC Web Feature Service (WFS) Standard
- OGC API Features
- OGC API: estándares de APIs geoespaciales orientadas a recursos
Laboratorio: compruebe el contrato antes de migrar
Prepare el endpoint sintético de pygeoapi. Ejecute este cliente Python sin dependencias adicionales. Comprueba conformidad declarada y estructura de una página; no afirma equivalencia con transacciones WFS ni con ArcGIS REST.
import json
from urllib.request import urlopen
base = 'http://localhost:5000'
with urlopen(base + '/conformance?f=json', timeout=10) as response:
conformance = json.load(response)
assert isinstance(conformance['conformsTo'], list)
with urlopen(base + '/collections/stations/items?f=json&limit=1', timeout=10) as response:
page = json.load(response)
assert page['type'] == 'FeatureCollection'
print('items:', len(page['features']))
print('next:', [link['href'] for link in page.get('links', []) if link['rel'] == 'next'])
Inventaríe por cliente las operaciones usadas: lectura por identificador, bbox, filtro, paginación, reproyección y escritura. Ejecute la misma consulta semántica en ambos servicios y compare identificadores y geometrías, no el orden incidental. Retenga WFS mientras un cliente necesario dependa de él. Ver la biblioteca de guías.
Lecturas relacionadas
- pygeoapi en producción: TLS, acceso, límites y monitoreo
- MapLibre: construya un mapa web con GeoJSON
Matriz de capacidades para contratar e implementar
| Requisito | Contrato WFS 2.0 | Contrato OGC API Features | Prueba |
|---|---|---|---|
| Descubrir recursos | Capacidades y tipos | Entrada y colecciones | Recurso visible al usuario previsto |
| Leer objetos | GetFeature y formato | Items y representaciones | Mismos IDs y valores |
| Revisar esquema | DescribeFeatureType | Esquema/queryables soportados | Tipos y valores nulos |
| Filtro espacial | Bbox/operaciones anunciadas | Bbox y extensiones implementadas | IDs conocidos dentro/fuera |
| Filtro de atributos | Capacidades de filtro | Propiedades/CQL2 soportados | Predicado realmente aplicado |
| Paginar | Parámetros según versión | Enlaces y parámetros anunciados | IDs completos sin duplicados |
| Otro CRS | Sistemas anunciados | Parte 2 si se implementa | Coordenadas y ejes correctos |
| Editar | Perfil transaccional habilitado | Capacidades adicionales soportadas | Validación, concurrencia y permisos |
OGC API Features Parte 1 define el contrato básico de lectura; no demuestra cualquier función de filtrado, CRS o edición. WFS 2.0 también requiere comprobar capacidades de la implementación. En una propuesta solicite versión y clases de conformidad concretas, no solo “soporta OGC”.
Ejecute la misma consulta de negocio por ambas interfaces
El laboratorio descargable publica activos sintéticos por distrito. Solicite D01 por ambos servicios y compare el conjunto de asset_id con la fuente. Use la sintaxis documentada de cada protocolo; no necesitan tener parámetros idénticos. Repita con bbox conocida, identificador inexistente, resultado vacío y límite entre páginas.
Registre geometría, orden de coordenadas, nulos y fechas. Si un consumidor ArcGIS requiere una operación REST de Esri, WFS y OGC API no deben llamarse reemplazo directo hasta modificarlo o probar un adaptador explícito. La guía de reemplazo de servicios desarrolla esa tarea diferente.