Course · ← 0004 Time and Mutation · 0006 Choosing the Stack →
Lesson 0005 · ~13 minutes
The service standards a donor RFP assumes you know — WMS, WFS, and the REST generation replacing them — plus the one coordinate mistake that silently moves every parcel you own.
Almost every spatial requirement resolves to one of two questions, and OGC gave each its own standard.
The distinction has procurement consequences. A requirement to publish cadastral parcels as WFS means anyone can download your parcel geometries in bulk; as WMS, they can only look. Across the EU, countries expose cadastral data exactly this way — WMS for view services, WFS for download services, under INSPIRE.1
WFS is a decade-old design: verbose, XML/GML, awkward for browsers. OGC has re-expressed the same capability as a resource-oriented REST API built on JSON, GeoJSON and OpenAPI 3.0 — OGC API — Features. OGC states plainly that the functional capabilities of WFS are now available in this more modern API and that implementers are encouraged to use the newer standard.2
Current parts: Features — Part 1: Core, Part 2: Coordinate Reference Systems by Reference, Part 3: Filtering. ogcapi.ogc.org. There is a parallel OGC API — Maps modernising WMS.
| Old | New | Serves |
|---|---|---|
| WMS | OGC API — Maps | Rendered map images |
| WFS | OGC API — Features | Vector features, GeoJSON |
| WMTS | OGC API — Tiles | Pre-cut tile pyramids |
Do not pick a side. Say: OGC API — Features as the primary interface, with WFS/WMS retained for compatibility. That is the direction of travel — the EU's Joint Research Centre is modernising the INSPIRE stack around using standards "as is", and OGC API — Features has been adopted as an INSPIRE Good Practice.3 Meanwhile every existing government client on the continent still speaks WMS, and will for years.
A CRS (coordinate reference system) defines how your numbers map to the earth. Each is identified by an EPSG code. Three you will meet constantly:
| Code | What | Use |
|---|---|---|
EPSG:4326 | WGS 84, geographic — degrees | Interchange, GPS, GeoJSON default |
EPSG:3857 | Web Mercator — metres, wildly distorted at high latitude | Web basemaps only |
| National grid (e.g. a UTM zone) | Projected, metres, minimal local distortion | Cadastral storage, area, distance |
Two rules that prevent most of the pain. Never compute area or distance in degrees — a degree of longitude is not a fixed length, so 4326 area figures are meaningless; project to the national grid first. And never store cadastral geometry in Web Mercator; it is a display projection, not a measurement one.
A wrong CRS rarely errors. It renders. Parcels appear — a few metres off, or in the wrong hemisphere, or subtly rotated — and nobody notices until a boundary dispute. Store the EPSG code with the data, declare it on every service, and test round-trips against known control points. Under general boundaries (lesson 0002) you already tolerate a metre or two of vagueness — which is exactly what makes a systematic 3-metre datum shift so easy to miss.
One more trap worth knowing before it costs you a day: axis order. EPSG:4326 is formally latitude-then-longitude, while GeoJSON and most web tooling use longitude-then-latitude. Different libraries resolve this differently. If your data lands neatly in the sea off West Africa at (0,0)-ish, or coordinates look transposed, this is usually why.
The OGC API landing page — the family, current parts, and which legacy standard each replaces:
ogcapi.ogc.org
Then skim "INSPIRE and OGC APIs — Modernizing INSPIRE" for the institutional argument you can reuse almost verbatim in a proposal.