OGC web services are the interoperability contracts of web mapping: standard interfaces through which any compliant client can request maps and data from any compliant server, regardless of vendor. WMS serves rendered map images, WMTS serves cached tiles, WFS serves the vector features themselves, WCS serves coverages. Their modern successors — the OGC API family — restate these contracts as clean RESTful JSON. Together they are why national portals, desktop GIS and web apps can all drink from the same sources.
The classic quartet
WMS answers “draw me this area” with a rendered image — simple, universal, style-controlled by the server. WMTS pre-renders into cached tile pyramids for speed at scale. WFS returns actual features with geometry and attributes — data you can query, style and analyse client-side. WCS does the same for rasters as data rather than pictures.
Choosing among them is a bandwidth-flexibility trade: images are cheap and closed; features are heavier and open to client-side use.
The OGC API generation
The XML-era services carry twenty years of wrinkles. OGC API — Features, Tiles, Maps, Records and kin — rebuilds them on HTTP best practice: JSON responses, resource-oriented URLs, OpenAPI descriptions, painless pagination. Adoption is spreading through servers and clients, with the older services remaining ubiquitous for years yet.
For architects the guidance is dual-stack: publish classic services for the installed base, adopt the APIs for new integrations.
Interoperability as policy
Standards matter beyond convenience: they are how spatial data infrastructures stay vendor-neutral and how public data remains accessible by mandate — INSPIRE and national SDI rules cite OGC interfaces explicitly. They also future-proof: services outlive the software that first published them.
Practical excellence lies in the details — sensible layer naming, metadata links, CRS support, performance tuning — the difference between a compliant endpoint and a usable one.