OGC API Features vs WFS: cómo elegir y migrar servicios vectoriales
Una comparación práctica para decidir cuándo mantener WFS, cuándo publicar OGC API Features y cómo hacer la transición sin romper consumidores existentes.
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.