OGC API Features vs WFS: choosing and migrating vector services
A practical comparison for deciding when to retain WFS, when to publish OGC API Features, and how to transition without breaking existing consumers.
WFS and OGC API Features are neither synonyms nor an automatic migration path. Both can publish geographic features for enquiry, but they serve different ecosystems and technical contracts. The right decision begins with real consumers, not with which acronym seems newer.
WFS 2.0 remains a valid way to provide fine-grained access to features and properties. OGC itself notes that its functional capabilities are available through a more modern web API and encourages implementers to consider OGC API Features for new work. That does not make an existing WFS a mistake, nor does it justify switching it off before clients have been tested.
GeoSAT's geospatial interoperability service can inventory services and design the transition. Before publishing, also use the metadata and GetCapabilities audit.
What changes between the two approaches
WFS defines discovery and query operations and, in applicable profiles, locking and transaction operations. Its clients commonly start with GetCapabilities, inspect the feature type and request results through service-defined parameters.
OGC API Features organises resources as a web API: a landing page, collections, items and, depending on the server, an OpenAPI definition and multiple formats. OGC describes it as a standard built on current web practices, including REST, OpenAPI, JSON and HTML.
The practical difference is not that one “has data” and the other does not. It is how a consumer discovers, understands, queries and maintains the service contract.
| Primary need | Sensible starting point |
|---|---|
| Compatibility with desktop workflows or integrations already proven against WFS | Retain WFS, document it and correct its metadata and limits. |
| A readable API for web applications, development teams and OpenAPI documentation | Evaluate OGC API Features for read-only collections. |
| Shared editing, locking, validation and change traceability | Design the edit workflow explicitly; do not assume a read API solves it. |
| Replacing a legacy platform without interrupting critical services | Publish in parallel, test consumers and retire only what has an accepted replacement. |
Inventory consumers before changing a route
A service may feed QGIS, ArcGIS, a bespoke viewer, a mobile app, an automated spreadsheet or an integration process no one remembers. Record for every consumer:
- URL, version, authentication and accountable owner.
- Operation or route used and usual filters.
- Required volume, frequency and response time.
- Format, CRS, stable identifier and fields it cannot lose.
- Expected behaviour for errors, features without geometry and empty results.
Not every client interprets paging, filters, projections or formats in the same way. The inventory turns “migrate services” into cases that can actually be run and approved.
Decide what is published and under which contract
Not every table in a database should become a public collection. Separate public, internal, restricted and controlled-exchange data. For every published collection, define a stable name, description, owner, licence, update date, spatial and temporal extent where applicable, available CRS, query limits and change policy.
Treat identifiers as part of the contract. If a feature changes key when it moves from WFS to an API, links, caches, forms and external references can lose their meaning even when the map still displays polygons.
Migrate through a parallel test
A cautious transition normally follows this sequence:
- Set a baseline. Save example queries, responses, counts, attributes and geometries from critical workflows.
- Publish a test collection. Use a visible environment name and authorised data; do not replace the production URL yet.
- Compare results. Check identifiers, spatial and attribute filters, encoding, nulls, CRS, paging and limits.
- Test real clients. Include the highest-risk consumers, not only a browser request.
- Prepare rollback. Define who authorises change, how the former service is restored and how source consumers are notified.
WFS and OGC API Features can coexist during a transition. Running two routes is an operational choice with testing, security and documentation costs; it should not become indefinite duplication without an owner.
Do not confuse an endpoint with interoperability
An endpoint is not interoperable merely because it returns a response. The service must explain what it publishes and keep that explanation true over time. Before accepting delivery, test that:
- An authorised external person can discover and understand the collection.
- Filters cannot reveal or infer restricted information.
- The response identifies source, cutoff, licence and use limitations.
- Traces, metrics and alerts exist for publication errors or anomalous queries.
- An update preserves, or documents changes to, schemas and identifiers.
For a Colombian organisation, these checks put catalogue, metadata and service principles into practice without claiming certification because a standard name appears in the architecture. Evidence depends on the data set, consumers and applicable institutional framework.
Next step
If the current WFS works, documenting it and testing recovery may be more valuable than replacing it for fashion. If a new portal or product needs a resource-oriented API, OGC API Features can be a more natural foundation. The right answer can include both for a controlled period.
GeoSAT can prepare the inventory, publication contract and transition tests. Then connect the decision to a sustainable geoportal architecture, where a service is an operable layer rather than the only copy of the data.