Build an OGC API Features service: a practical guide
OGC API Features is a modern, HTTP-based standard for publishing and querying geospatial features. This guide explains how to design a compliant read-only service, expose discoverable collections, implement feature queries, validate geometry and coordinate reference systems, and prepare the service for real geographic workloads.
An OGC API Features service gives applications a predictable way to discover and retrieve vector geospatial data over the Web. Instead of requiring every consumer to understand a vendor-specific database, file format, or legacy service interface, the API exposes a landing page, conformance information, collections, and individual feature-query endpoints. The core standard is focused on read access, with additional OGC API Features parts covering coordinate reference systems, filtering, and other capabilities. (ogc.org) This guide builds the service from the outside in: first define the resource contract, then connect it to a spatial data source, then add filtering, pagination, validation, and operational safeguards. The examples use HTTP, JSON, and GeoJSON because those are common implementation choices, but OGC API Features is an API standard rather than a prescribed database or programming language.
How EDK fits
For: Developers and geospatial engineers building a standards-based feature service for web maps, GIS clients, location-data applications, spatial analysis pipelines, or public-data distribution.
OGC API Features is a useful interoperability layer between raw geographic sources and systems that need to find, understand, and compute about real-world features. A service can expose roads, buildings, waterways, public assets, permits, environmental observations, or other feature collections using consistent discovery and query patterns. That makes the physical world easier for applications to retrieve and relate to other geographic information. In an E2-style world-model workflow, an OGC API Features endpoint could serve as one authoritative external source: clients can discover a collection, constrain it by bounding box or time, retrieve individual features, and then combine those results with other places, infrastructure, imagery, or event data for proximity, ranking, aggregation, change analysis, or regional computation. This connection describes an interoperability pattern, not a claim that the external service provides E2 capabilities.
- •Use an OGC API Features endpoint as a standards-based source for discovering and retrieving physical features such as roads, buildings, streams, parks, public assets, or service locations before combining them with other geographic layers for spatial analysis.
- •Use collection metadata, bounding-box queries, pagination, and feature properties to support computations about the physical world, such as counting features within an area, comparing conditions across regions, or finding nearby infrastructure. The external service remains the source of the published features; the computation occurs in the consuming system.
The EDK outcome
Before you start
A dataset of geographic features with stable identifiers and documented provenance.
A server-side runtime capable of handling HTTP requests and returning JSON or HTML.
A spatially aware source or library that can filter features by at least bounding box and, where applicable, time.
A clear decision about the service’s supported OGC API Features conformance classes.
Basic familiarity with HTTP, JSON, GeoJSON, coordinate reference systems, and spatial indexes.
Learning objectives
Design the core resource structure of an OGC API Features service.
Expose discoverable collections with useful spatial and temporal metadata.
Implement bounded feature retrieval with bbox, datetime, pagination, and content negotiation where supported.
Avoid common CRS, coordinate-order, geometry-validity, and identifier mistakes.
Understand how a feature API can feed broader geographic search and computation without replacing other geospatial services.
Verification
The root landing page is reachable and its links resolve.
The /conformance response contains only implemented and tested conformance classes.
Every listed collection has stable metadata and an accurate spatial extent.
Feature responses contain valid feature identifiers and valid or explicitly null geometries.
Coordinates are in the declared CRS and use the expected longitude/latitude order for Part 1 Core.
bbox and datetime filters are validated and produce repeatable results against a fixed dataset snapshot.
Pagination does not return duplicate or skipped features under the service’s documented consistency model.
The service returns useful errors for unknown collections, invalid parameters, unsupported formats, and unauthorized access.
The service identifies data provenance, attribution, licensing, and freshness.
Troubleshooting
If a client shows no collections, inspect the landing-page links and confirm that /collections returns the expected JSON media type. A valid items endpoint is not enough if discovery is broken.
If geometries appear shifted, verify coordinate order and CRS transformation. Do not fix a display problem by changing metadata without transforming coordinates.
If bbox queries return too many or too few features, check whether the implementation is testing feature intersection, geometry envelopes, or another predicate. Document the chosen behavior and test boundary cases.
If pagination is slow, inspect the query plan, add or repair spatial and attribute indexes, reduce the default page size, and avoid counting the entire result set unless the client truly needs an exact total.
If clients reject the response, compare the response media type, FeatureCollection structure, feature IDs, links, and advertised conformance classes against the official Part 1 requirements.
If results change between pages, define a snapshot or cursor strategy for mutable data. Offset pagination over a live table can produce duplicates or omissions.
If a projected dataset is being served as WGS 84, perform a real coordinate transformation and verify it with known control points.
If rich filters are unavailable, do not silently accept unsupported parameters. Return a clear error or document that the service currently supports only the core query model.
Next steps
Add the production-focused guide for deployment, caching, observability, authentication, and refresh pipelines.
Add a troubleshooting runbook covering CRS, pagination, discovery, geometry, and client interoperability failures.
Evaluate Part 2 for alternate CRS support and Part 3 or CQL2 for richer filtering only after the core service is stable.
Connect the service to a spatial analysis workflow for regional aggregation, proximity calculations, quality checks, and change detection.
Publish a data-quality statement explaining completeness, positional accuracy, update frequency, temporal coverage, and known exclusions.
What you need before writing code
You need a dataset containing identifiable geographic features, a way to read those features, and a service runtime capable of handling HTTP requests and returning JSON or HTML representations. The standard does not require PostgreSQL, PostGIS, a particular language, or a particular deployment model. Your source could be a spatial database, a file-backed store, an existing catalog, or another service, provided that your implementation can produce the required API resources.
Start by deciding what each collection represents. A collection might contain residential roads, building footprints, streams, hydrants, permits, or service requests. Avoid creating one collection that mixes unrelated feature types unless the shared schema and query behavior are genuinely useful. Record each collection’s identifier, title, description, spatial extent, temporal extent when applicable, supported media types, and attribution. The OGC overview describes collections as discoverable resources with identifiers, descriptions, and spatial or temporal extents. (ogcapi.ogc.org)
- •A versioned dataset or database snapshot.
- •Stable feature identifiers within each collection.
- •A documented geometry type and property schema.
- •A decision about whether timestamps represent observation time, publication time, or another temporal concept.
- •A policy for attribution, licensing, access control, rate limits, and data refreshes.
- •A test client such as curl, a browser, QGIS, GDAL, or a small Python script.
Step 1: implement the discovery resources
An OGC API Features client should be able to start at the service root and follow links to learn what the service provides. Implement these resources before optimizing the database query: the landing page at /, conformance information at /conformance, the collection index at /collections, a collection description at /collections/{collectionId}, and feature queries at /collections/{collectionId}/items. The common OGC API building blocks define the landing page, conformance information, links, and machine-readable API descriptions as part of a predictable Web API structure. (docs.ogc.org)
A minimal inspection workflow looks like this:
- •Keep collection identifiers stable; changing an identifier breaks bookmarked URLs and client configuration.
- •Use links with explicit relation types and media types where required by the standard.
- •Return useful human-readable HTML when practical, while preserving machine-readable JSON.
- •Expose an OpenAPI description so developers can inspect parameters and responses. The OGC API site provides developer-friendly OpenAPI definitions for the Features standard. (ogcapi.ogc.org)
Step 2: implement feature retrieval and query parameters
The core feature endpoint is /collections/{collectionId}/items. A request without additional filters should return a paginated FeatureCollection rather than an unbounded export. Each returned feature needs a stable identifier, a geometry when available, and properties that describe the feature. GeoJSON is widely supported by OGC API Features implementations, although the standard is broader than a single client library or storage format. (ogc.org)
Begin with a small, explicit query contract:
- •Push bbox filtering into the spatial database or indexed source instead of downloading the whole dataset into application memory.
- •Select only the properties and geometry detail needed for the response.
- •Use spatial indexes for bounding-box and intersection candidates.
- •Treat feature IDs as identifiers, not as row numbers that can silently change after a reload.
- •Return clear HTTP errors for unknown collections, invalid parameters, unsupported media types, and authorization failures.
Step 3: connect the API to spatial computation and production operations
Once the basic endpoints work, connect each query to a tested spatial execution path. In a database-backed service, the typical sequence is: validate request parameters, resolve the collection configuration, apply temporal and attribute filters, apply the spatial predicate, order or page the result, transform geometry if required, serialize the response, and add navigation links. Keep the API layer separate from the source-specific query code so that a database migration does not change the public contract.
Measure the difference between geographic retrieval and geographic computation. A bbox query can narrow the candidate area, but it does not by itself answer whether features intersect a complex polygon, lie within a network distance, or are nearest to a point. Those operations may require additional filtering capabilities or downstream spatial processing. OGC API Features Part 3 addresses filtering, and CQL2 is a related OGC standard for expressing richer filter conditions; implement those only when you can document and test the supported predicates. (ogc.org)
- •Version the dataset independently from the API implementation and record the effective date of each release.
- •Cache stable collection metadata and immutable feature responses when licensing and freshness rules allow it.
- •Use contract tests for /, /conformance, /collections, collection metadata, and representative /items queries.
- •Test empty collections, null geometries, invalid geometries, duplicate IDs, long property values, and very large responses.
- •Document what the service does not provide: editing, tiles, routing, geocoding, authoritative basemap display, or arbitrary analysis unless separately implemented.
Workflow
1. Inventory and model the source data
Choose collection boundaries, stable IDs, geometry types, property names, provenance, licensing, spatial extent, temporal meaning, and refresh policy. Keep the public schema explicit rather than exposing internal database columns accidentally.
# Example collection design
roads: id, geometry(LineString), name, road_class, updated_at
hydrants: id, geometry(Point), material, access_type, inspected_at2. Create the landing page and conformance resources
Implement GET / with title, description, attribution, and links to /conformance, /collections, and the API definition. Implement GET /conformance and advertise only the conformance classes that are actually tested.
curl -sS https://example.gov/geospatial/ | jq
curl -sS https://example.gov/geospatial/conformance | jq3. Publish collection metadata
Implement GET /collections and GET /collections/{collectionId}. Include identifiers, descriptions, links, media types, spatial extent, and temporal extent when meaningful. Make the collection description sufficient for a client to understand what a returned feature represents.
curl -sS https://example.gov/geospatial/collections | jq
curl -sS https://example.gov/geospatial/collections/roads | jq4. Implement bounded feature queries
Implement GET /collections/{collectionId}/items. Start with limit, bbox, datetime, and response-format handling if supported. Validate every parameter before querying the source and return navigation links for additional pages.
curl -sS \
'https://example.gov/geospatial/collections/roads/items?bbox=-122.45,37.74,-122.39,37.80&limit=100' \
-H 'Accept: application/geo+json' | jq5. Add spatial indexes and response controls
Push spatial predicates into the data source, cap page sizes, select only needed columns, simplify geometry only when the published semantics permit it, and monitor query duration and response size. Use caching for stable metadata and immutable data where appropriate.
# Illustrative database-side pattern, not a required implementation
SELECT id, geometry, name, road_class
FROM roads
WHERE geometry && ST_MakeEnvelope(:west, :south, :east, :north, 4326)
LIMIT :page_size;6. Test conformance and client behavior
Test direct HTTP requests, a standards-aware client, invalid parameters, empty results, null geometries, duplicate IDs, CRS assumptions, pagination, and large responses. Compare advertised conformance with observed behavior before publishing the endpoint.
curl -iS 'https://example.gov/geospatial/collections/roads/items?limit=25'
curl -iS 'https://example.gov/geospatial/collections/not-a-collection/items'Questions teams ask
Is OGC API Features the same thing as WFS?
No. OGC API Features is a newer, resource-oriented Web API standard that uses common Web patterns such as HTTP resources, links, JSON, HTML, and OpenAPI. WFS is a separate OGC Web Feature Service standard with a different interface lineage. An OGC API Features service should be evaluated through its advertised conformance and resources rather than assumed to be a WFS endpoint. (docs.ogc.org)
Do I need PostGIS to build an OGC API Features service?
No. The standard defines the API behavior, resource structure, and response expectations; it does not prescribe a database. PostGIS is a practical choice when you need indexed spatial filtering, geometry validation, CRS transformation, and spatial predicates, but a file-backed or other spatial source can also work if it can meet the service contract and performance requirements.
Should every feature query return the entire dataset?
No. Use bounded responses with a default and maximum limit, spatial or temporal filters where supported, and navigation links for additional pages. Returning an unbounded collection makes latency, memory use, and service availability unpredictable.
When do I need OGC API Features Part 2?
Use Part 2 when the service must present geometries in coordinate reference systems other than the WGS 84 longitude/latitude arrangement required by Part 1 Core. If all clients can consume WGS 84 longitude/latitude, start with Part 1 and avoid advertising an extension you do not implement. (ogc.org)
Can OGC API Features replace a vector-tile service or routing API?
Not by itself. OGC API Features is for discovering and querying feature data. Vector tiles optimize tiled visualization, while routing APIs compute paths through transportation networks. You may use the same underlying geographic sources for all three, but they serve different response and computation needs.
Keep exploring
build an ogc api features service production guide
Continue from the core implementation into deployment, caching, observability, data refreshes, and production operations.
build an ogc api features service troubleshooting guide
Use the troubleshooting workflow when discovery, CRS, pagination, filtering, geometry, or client-integration failures appear.
consume wfs in python
Compare a legacy OGC feature-service consumption workflow with the resource-oriented OGC API Features approach.
analyze spatial data with geopandas
Load API responses into a Python spatial-analysis workflow for joins, measurements, filtering, and aggregation.
Sources
OGC API Features Standard
Authoritative overview of the multi-part standard, including Part 1 Core, Part 2 CRS by Reference, Part 3 Filtering, and the scope of the API.
Open sourceOGC API Features official overview and developer resources
Official OGC API site with the feature-collection model, standards documents, and developer-friendly OpenAPI definitions.
Open sourceOGC API Features Part 1: Core
The approved Part 1 Core standard defining the fundamental feature API resources and WGS 84 longitude/latitude core behavior.
Open sourceOGC API Common Part 1: Core
Authoritative specification for common landing-page, conformance, links, discovery, and Web API building blocks.
Open sourceFeatures and Geometries JSON Standard
Official OGC reference for JSON feature and geometry encoding context, including its relationship to GeoJSON and OGC API Features.
Open source