5.4 Open Standards and Interoperability: OGC Web Services & Open Formats

5.4 Open Standards and Interoperability: OGC Web Services & Open Formats

Core Principle: Geospatial interoperability is the ability of disparate computing systems, software applications, and web services to exchange, interpret, and process geographic data seamlessly without manual conversion or data loss. Governed primarily by the Open Geospatial Consortium (OGC), open standards prevent proprietary vendor lock-in, enable cloud-native spatial analytics, and empower distributed spatial data infrastructures (SDIs).

---

1. The Open Geospatial Consortium (OGC) Framework

Founded in 1994, the Open Geospatial Consortium (OGC) is an international non-profit voluntary consensus standards organization comprising commercial software vendors, government agencies, universities, and open-source communities. OGC standards are publicly available, royalty-free specifications that establish common data models, encodings, and communication protocols across the geomatics industry.

Open Standards vs. Proprietary Formats

• Open Standards: Developed through transparent, consensus-driven processes (e.g., OGC, ISO/TC 211, IETF, W3C). Specifications are fully documented, freely accessible, and implementable by any developer without licensing fees or legal encumbrances (e.g., GeoPackage, GeoJSON, WMS, WFS).
• Proprietary Formats: Owned and controlled by a single commercial entity. The underlying data specifications may be closed or patented. Even when a specification is published (such as the Esri Shapefile Technical Description), updates, extensions, and changes remain at the sole discretion of the owning corporation.

---

2. OGC Web Services (OWS) Architecture

The traditional OGC Web Service (OWS) architecture operates on standard HTTP protocols using Key-Value Pair (KVP) queries via HTTP GET requests or XML payloads via HTTP POST requests. Every classical OGC service shares a common foundational request:

The GetCapabilities Operation

Every OWS endpoint must implement GetCapabilities. When invoked by a client (e.g., https://geoserver.example.gov/wms?SERVICE=WMS&REQUEST=GetCapabilities), the service responds with a standardized XML document detailing:

• Service Metadata: Contact details, fees, access constraints, and standard version.
• Supported Operations: Allowed requests (e.g., GetMap, GetFeatureInfo).
• Available Layers / Feature Types: Layer names, bounding boxes, and supported Coordinate Reference Systems (CRSs).

                  OGC WEB SERVICES ARCHITECTURAL MATRIX
                  
                     +-------------------------------+ 
                     | Client Application (GIS/Web)  | 
                     +-------------------------------+ 
                                     | 
         +---------------------------+---------------------------+ 
         |                           |                           | 
         v                           v                           v 
   [WMS / WMTS]                   [WFS]                       [WCS] 
   Web Map Service           Web Feature Service        Web Coverage Service 
         |                           |                           | 
         v                           v                           v 
   Rendered Map Image        Vector Geometries           Raw Raster Grids 
   (PNG, JPEG Tiles)         (GML, GeoJSON, GeoHash)     (GeoTIFF, NetCDF Values) 
         |                           |                           | 
   Visual Display Only       Analytical Vector Math      Surface / Elevation Math 
   (No Native Vectors)       Client-Side Styling         Pixel Values = Real Data

---

3. Core OGC Web Service Specifications: WMS, WMTS, WFS, and WCS

Understanding the exact functional division among the four primary OWS standards is one of the most heavily tested subjects on the GISP exam.

1. Web Map Service (WMS - OGC 06-042 / ISO 19128)

WMS serves dynamically rendered georeferenced map images. When a client requests data, the server queries its internal database, applies server-side symbology and labeling rules, rasterizes the layers on-the-fly, and streams a single composite image back to the client.

• Core Operations:
  • GetCapabilities: Returns service metadata and layer list.
  • GetMap: Returns the rendered map image.
  • GetFeatureInfo: Queries attributes of a feature by clicking an image pixel ($X, Y$).
• Mandatory GetMap URL Parameters:
  • LAYERS: List of layer names to render.
  • STYLES: Pre-defined server-side styles (or SLD - Styled Layer Descriptor).
  • CRS (or SRS in WMS 1.1.1): Coordinate Reference System (e.g., EPSG:4326, EPSG:3857).
  • BBOX: Bounding box coordinates (minx,miny,maxx,maxy).
  • WIDTH & HEIGHT: Pixel dimensions of output image.
  • FORMAT: Output MIME image format (e.g., image/png, image/jpeg).
• Strengths and Weaknesses: Excellent for complex, proprietary styling and real-time database updates; high server computational load when handling thousands of concurrent users.

2. Web Map Tile Service (WMTS - OGC 07-057r7)

To resolve the high server processing overhead of dynamic WMS rendering, WMTS serves pre-rendered, pre-cached image tiles arranged in a standardized pyramid matrix.

• Tile Matrix Set: A multi-scale hierarchy where each zoom level (TileMatrix) doubles the spatial resolution and quadruples the tile count. Tiles are uniformly addressed by Zoom Level, Column, and Row (Z / X / Y).
• Core Operations: GetCapabilities, GetTile (requests a specific cached tile by matrix index), and GetFeatureInfo.
• Strengths: Near-zero server rendering load; extreme scalability via Content Delivery Networks (CDNs); sub-second load times for web mapping base maps.

3. Web Feature Service (WFS - OGC 09-025r2 / ISO 19142)

Unlike WMS which delivers flattened pictures, WFS serves raw vector geometries and attributes. The client receives the actual spatial coordinates (points, lines, polygons) and tabular fields encoded in Geography Markup Language (GML), GeoJSON, or binary formats.

• Client Control: The client software performs local rendering, local symbolization, spatial queries, geometric editing, and local spatial analysis.
• Core Operations:
  • GetCapabilities: Discovers feature types.
  • DescribeFeatureType: Returns the XML Schema (.xsd) defining field names and attribute types.
  • GetFeature: Extracts actual vector features, supporting spatial and attribute filtering (via OGC Filter Encoding standard fes:).
• Transactional WFS (WFS-T): Enables clients to execute web-based spatial editing. Through the Transaction operation, authorized web users can create (Insert), modify (Update), or delete (Delete) vector features directly in an enterprise spatial database over HTTP.

4. Web Coverage Service (WCS - OGC 09-110r4)

WCS serves raw, unrendered digital values representing space-varying phenomena. It delivers analytical raster data rather than visual graphics.

• Data Types: Digital Elevation Models (DEMs), multi-spectral satellite imagery, radar backscatter, sea surface temperatures, and meteorological weather models.
• Core Operations: GetCapabilities, DescribeCoverage, and GetCoverage.
• The Critical Distinction: A WMS GetMap request of a DEM returns a PNG picture where each pixel is an RGB color (e.g., shades of brown and green). A WCS GetCoverage request of the same DEM returns the raw floating-point elevation values in meters (e.g., 32-bit GeoTIFF), enabling the client to compute slope, aspect, cut-and-fill volumetrics, or hydrologic flow paths.

---

4. OWS Comparison Summary

---

5. The Modern Evolution: OGC API Standards

The traditional OWS specifications relied heavily on rigid XML schemas, SOAP messaging, and Key-Value Pair query strings developed during the early 2000s. To modernize spatial web architectures, the OGC launched the OGC API standard family, built upon modern web principles:

• RESTful Resource Architecture: Spatial entities are identified as web resources via predictable, hierarchical URIs (e.g., https://api.example.gov/collections/parcels/items/10492).
• OpenAPI 3.0 Compliance: Standardized API documentation enabling automated interactive developer documentation (Swagger/ReDoc) and automated client code generation.
• Standard JSON/GeoJSON Payloads: Replacing complex GML schemas with lightweight, native web JSON.
• Modular Architecture: Core standards include OGC API - Features (modern REST successor to WFS), OGC API - Tiles (successor to WMTS), OGC API - Coverages (successor to WCS), and OGC API - Records (successor to CSW).

6. Open Geospatial Data Formats

Selecting the appropriate file format dictates interoperability, analytical performance, and data longevity. Modern GIS workflows increasingly replace legacy file structures with open, robust containers.

1. OGC GeoPackage (GPKG - OGC 12-128r17)

The GeoPackage standard is an open, non-proprietary, platform-independent SQLite 3 container format designed for storing both vector features and raster tile pyramids in a single standalone file (.gpkg).

• Internal Architecture: Built upon an embedded relational SQLite database file. Contains standardized schema tables including gpkg_spatial_ref_sys (CRS definitions), gpkg_contents (layer registry), and gpkg_geometry_columns.
• Direct Querying: Supports spatial SQL queries (via SpatiaLite SQL extensions) directly on the file without requiring a running database server daemon.
• Capabilities: Supports vector points, lines, polygons, non-spatial attribute tables, raster elevation and imagery tile pyramids, and user-defined schema extensions.
• Advantages: Completely open; single-file simplicity; zero size limits beyond SQLite's 140-terabyte maximum; supports full UTF-8 character encoding; handles NULL values properly.

2. GeoJSON (IETF RFC 7946)

Standardized by the Internet Engineering Task Force (IETF) in 2016, GeoJSON is a lightweight, human-readable data interchange format based on JavaScript Object Notation (JSON).

• Strict Coordinate Reference System: RFC 7946 mandates that all coordinates must be referenced to the WGS84 geographic coordinate system (urn:ogc:def:crs:OGC::CRS84 / EPSG:4326), using decimal degrees.
• Coordinate Ordering: The standard strictly enforces Longitude first ($X$), Latitude second ($Y$): [longitude, latitude, elevation].
• Geometry Types: Standardizes seven geometries: Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon, and GeometryCollection.
• Features and Collections: Structured as Feature objects containing geometry and a properties key-value dictionary, aggregated within a top-level FeatureCollection.
• Limitations: Highly verbose text encoding; inefficient for massive datasets (>50 MB); lacks spatial indexing in raw form.

3. Keyhole Markup Language (KML / KMZ - OGC 07-147r2)

Originally created by Keyhole Inc. and popularized by Google Earth, KML was standardized by the OGC in 2008. It is an XML-based format focused on 3D Earth visualization, placemarks, camera viewpoints, and cartographic styling. A KMZ file is simply a zipped archive containing a primary doc.kml file along with referenced icons, ground overlays, and 3D COLLADA models.

---

7. The Esri Shapefile: Architecture and Technical Limitations

Introduced in the early 1990s for ArcView 2, the Shapefile remains widespread in GIS but represents an antiquated, non-topological spaghetti format burdened by severe technical constraints.

Mandatory Component Files

A shapefile is not a single file; it is a directory collection of multiple companion files sharing a common prefix:

• .shp (Mandatory): The primary file storing the feature geometry coordinate strings.
• .shx (Mandatory): The spatial index file storing positional byte offsets to accelerate reading the .shp file.
• .dbf (Mandatory): The dBASE IV tabular database file storing attribute records.
• .prj (De Facto Standard): Plain text file storing the Coordinate Reference System in Well-Known Text (WKT) format.
• .cpg (Optional): Specifies the character code page encoding (e.g., UTF-8, ANSI).
• .sbn / .sbx (Optional): Proprietary spatial index files generated by commercial software.

Architectural Limitations of the Shapefile

---

8. Format Comparison Matrix

---

9. GISP Exam Traps & Pitfalls

• Trap: Conflating WMS with WCS: A Web Map Service returns an image (picture) of geographic data. Even if it displays elevation data, it returns an RGB image (PNG/JPEG) suitable only for visual cartography. A Web Coverage Service returns actual numerical values (floating-point elevation, radiance, temperature) suitable for spatial modeling.
• Trap: GeoJSON Coordinate Ordering: In common cartographic conversation, people say "Latitude, Longitude" ($Y, X$). However, GeoJSON RFC 7946 strictly mandates [Longitude, Latitude] ($X, Y$). Swapping coordinate order in GeoJSON places points on the wrong hemisphere or in outer space.
• Trap: GeoPackage is SQLite, not PostGIS: GeoPackage uses an embedded SQLite database container, meaning it is a standalone portable file. It does not require a PostgreSQL/PostGIS database server to operate, though it shares spatial SQL syntax roots.