Study guide

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

GISP Geospatial Core Technical Knowledge Exam Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: GISP Exam Structure, Policies & Preparation Strategy

1.1 GISP Certification Framework, Pearson VUE Delivery & Passing Standard 1.2 The 10 Official GISCI Knowledge Categories & Diagnostic Study Planning 1.3 Question Reasoning, Vendor-Neutral Concepts & Test-Taking Tactics

2 Chapter 2: Geodesy, Datums & Earth Geometry

2.1 Earth Geometry: Geoid, Reference Ellipsoids, and Heights 2.2 Horizontal & Vertical Datums: NAD27, NAD83, WGS84, NAVD88, and Modernized NSRS 2.3 Geomatics Disciplines, Geodetic Control Networks, and Monumentation

3 Chapter 3: Coordinate Systems & Map Projections

3.1 Geographic (GCS) vs. Projected (PCS) Coordinate Systems & Angles 3.2 Projection Families & Distortion Properties 3.3 Standard Projected Systems: State Plane (SPCS), UTM, and Web Mercator

4 Chapter 4: Vector & Raster Spatial Data Models

4.1 Vector Data Architecture: Points, Lines, Polygons, Multipart Features & Curves 4.2 Raster Architecture: Grid Structures, Pixel Dimensions & Multi-Dimensional Resolutions 4.3 Modeling Geographic Phenomena: Discrete Objects vs. Continuous Fields 4.4 Elevation and Surface Representations: DEMs, DSMs, DTMs, TINs, and Point Clouds

5 Chapter 5: Topology, Data Quality & Geospatial Standards

5.1 Spatial Topology: Planar Enforcement, Adjacency, Connectivity & DE-9IM 5.2 Data Quality Dimensions and Positional Accuracy Standards (ISO 19157-1, NSSDA, RMSE) 5.3 Geospatial Metadata Standards: FGDC CSDGM and the ISO 19115 Family 5.4 Open Standards and Interoperability: OGC Web Services & Open Formats

6 Chapter 6: Cartographic Design & Visual Variables

6.1 Visual Variables (Bertin's Semiology of Graphics) and Map Symbology 6.2 Map Design Hierarchy, Common Elements, Layout Balance & Typography 6.3 Color Theory, Palette Types & Accessible Cartographic Design

7 Chapter 7: Thematic Mapping & Data Classification

7.1 Thematic Map Types: Choropleth, Proportional/Graduated Symbol, Dot Density, Isarithmic & Cartograms 7.2 Data Classification Methods: Natural Breaks, Quantile, Equal Interval, Geometric Interval & Standard Deviation 7.3 Terrain Representation & 3D Visualization: Shaded Relief, Slope, Aspect, Curvature & Oblique Views

8 Chapter 8: Field Data Acquisition & GNSS

8.1 GNSS Constellations, Signal Structures, Error Budgets & Differential Correction (DGPS, RTK, PPP) 8.2 Heads-Up & Tablet Digitizing, Snapping Tolerances, Stream Mode & Boundary Capture 8.3 Mobile Field GIS Workflows, Disconnected Editing, GNSS Integration & Crowdsourced/VGI Data

9 Chapter 9: Remote Sensing & Imagery

9.1 The Electromagnetic Spectrum, Atmospheric Windows, Spectral Signatures & Sensor Types 9.2 Aerial Photogrammetry: Relief Displacement, Parallax, Orthorectification & Ground Control 9.3 Active Remote Sensing: LiDAR, RADAR, Synthetic Aperture Radar (SAR) & UAS/Drone Mapping

10 Chapter 10: Georeferencing, Transformations & Resampling

10.1 Georeferencing: Control Points, Root Mean Square Error & Transformation Models (Affine, Similarity, Projective, Spline) 10.2 Raster Resampling Techniques: Nearest Neighbor, Bilinear Interpolation & Cubic Convolution 10.3 Datum Transformations: 3-Parameter, 7-Parameter Helmert, and Grid-Based Shifts (NADCON, HARN)

11 Chapter 11: Data Integration & Spatial Generalization

11.1 Geospatial ETL: Format Conversion, Schema Mapping & Coordinate Translation 11.2 Spatial Generalization: Selection, Simplification, Smoothing, Aggregation, Collapse & Displacement 11.3 Conflation, Edge-Matching, Rubber-Sheeting & Data Harmonization

12 Chapter 12: Vector Analysis & Overlay Operations

12.1 Attribute and Spatial Query Languages: SQL WHERE Clauses and Spatial Predicates 12.2 Vector Geometric Overlay: Intersect, Union, Identity, Erase, Symmetrical Difference & Update 12.3 Proximity Analysis: Euclidean Distance, Fixed & Variable Buffers, Voronoi/Thiessen Polygons

13 Chapter 13: Raster Analysis, Surfaces & Spatial Statistics

13.1 Map Algebra & Raster Overlay: Local, Focal, Zonal & Global Operations 13.2 Surface Analysis & Spatial Interpolation: IDW, Kriging, Spline & Viewshed Analysis 13.3 Network Analysis: Geometric Networks, Utility Networks & Routing 13.4 Spatial Statistics & Pattern Analysis: Spatial Autocorrelation, Hot Spots & Regression

14 Chapter 14: Geospatial Database Design & Multiuser Architecture

14.1 Relational Database Foundations & Geospatial Extensions (SQL, PostGIS, SpatiaLite) 14.2 Geodatabase Schema Architecture: Feature Datasets, Subtypes & Attribute Domains 14.3 Spatial Indexing & Storage Structures: R-Tree, Quadtree, Geohash & Vector Tiles 14.4 Multiuser Geodatabase Architecture: Traditional Versioning, Branch Versioning & Archiving

15 Chapter 15: GIS Programming, Automation & Web Services

15.1 Python for GIS Automation: Scripting, Spatial DataFrames & Geospatial Libraries 15.2 Visual Programming, Workflow Modeling & Script Tools 15.3 Web GIS Architecture: REST APIs, Feature Services, Vector Tiles & Cloud Platforms

16 Chapter 16: Enterprise Architecture, Systems Security & Cloud Platforms

16.1 Enterprise GIS Architecture, Server Tiers, Sizing & Capacity Planning 16.2 Cloud GIS, Virtualization, Containers & High Availability (HA) 16.3 Enterprise GIS Security, Authentication, Authorization & System Auditing

17 Chapter 17: GIS Ethics, Legal Frameworks & Professional Practice

17.1 GISCI Code of Ethics & Rules of Conduct: Obligations to Society, Employers, Colleagues & Individuals 17.2 Legal Frameworks: Copyright, Intellectual Property, Licensing & Liability 17.3 Location Privacy, Geoprivacy & Spatial Data Confidentiality 17.4 GIS Project Management, Governance, Data Custodianship & Professional Practice

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

Key Takeaways Explain This Topic AI

The Open Geospatial Consortium (OGC) is an international consensus standards organization that develops vendor-neutral, open specifications to ensure spatial data interoperability and prevent vendor lock-in.

OGC Web Services (OWS) follow standard client-server protocols: WMS serves dynamically rendered map images, WMTS serves pre-rendered cached map tiles, WFS serves raw vector feature geometry and attributes, and WCS serves raw raster analytical values.

Transactional Web Feature Service (WFS-T) extends standard WFS by enabling clients to directly create, update, and delete vector features on remote database servers.

Modern OGC API standards transition from XML-heavy SOAP/KVP architectures to RESTful JSON/GeoJSON web interfaces compliant with OpenAPI 3.0 guidelines.

The OGC GeoPackage standard provides an open, cross-platform SQLite container that eliminates historic Shapefile limitations, such as the 2GB file size cap and 10-character attribute name truncation.

Last updated: September 2026

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 X, Y 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

Specification Primary Data Type Client Payload Primary Function Typical Use Case

WMS Rendered Map Graphics Dynamic Raster Image (PNG, JPEG) Visual Cartography Dynamically styled overlay layers, real-time vehicle tracking.

WMTS Pre-rendered Tile Cache Cached Raster Image Tiles High-Performance Display Web base maps (aerial imagery, street navigation tiles).

WFS Vector Features Coordinate Strings & Attributes (GML/GeoJSON) Spatial Analysis & Editing Downloading parcel lines, running client buffers, spatial editing.

WFS-T Vector Transactions XML Transaction Payloads Web-Based Data Entry Field crew collecting utility assets via mobile web apps.

WCS Continuous Coverages Raw Pixel Values (GeoTIFF, NetCDF, HDF) Scientific Modeling Extracting elevation grids for hydraulic modeling, NDVI analysis.

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).

Loading diagram... OGC Web Service Request-Response Architecture

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 X X ), Latitude second ( Y Y 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

Shapefile Limitation Technical Root Cause Modern Impact / Failure Mode

2-Gigabyte File Size Limit 32-bit file offset pointers stored in the .shp and .dbf file headers. Large LiDAR, parcel, or sensor datasets fail to export or become corrupted when reaching 2.147 GB 2.147\text{ GB} 2.147 GB .

10-Character Field Name Cap dBASE IV table architecture limits column headers to 10 bytes. Descriptive database column names (e.g., INSPECTION_DATE ) are truncated to cryptic strings ( INSPECTI_1 ).

Maximum 255 Attributes dBASE IV column indexing limits. Wide demographic or environmental datasets cannot be stored in a single table.

No True NULL Support dBASE format does not support standard SQL NULL values. Missing numeric values default to 0 or -9999 , skewing statistical analyses (averaging zero rainfall instead of NULL).

Single Geometry per File Architecture strictly restricts each file to a single geometry type. A shapefile cannot mix points, lines, and polygons, nor can it store raster grids.

Multi-File Fragility Separated geometry ( .shp ) and attributes ( .dbf ). Emailing or moving a dataset without copying all companion files permanently breaks the dataset.

No Built-in Topology Spaghetti vector model. Shared boundaries are stored redundantly, leading to slivers and unassigned gaps.

8. Format Comparison Matrix

Evaluation Metric Shapefile OGC GeoPackage GeoJSON (RFC 7946) File Geodatabase (FGDB)

Standard Ownership Proprietary Esri (Published Spec) Open Consensus (OGC) Open Standard (IETF) Proprietary Esri

Container Type Multi-file directory ( 3 3 3 to 8 8 8 files) Single SQLite 3 file ( .gpkg ) Single text file ( .geojson ) Directory folder ( .gdb )

Maximum File Size 2 GB 2\text{ GB} 2 GB per component file 140 TB 140\text{ TB} 140 TB (SQLite limit) Practical web limit ∼ 50 MB \sim 50\text{ MB} ∼ 50 MB 1 TB 1\text{ TB} 1 TB (extendable to 256 TB 256\text{ TB} 256 TB )

Supported Geometries Single vector type per file Points, Lines, Polygons, Raster Tiles Points, Lines, Polygons, Multi-part Multi-vector, Raster, Topologies, Networks

Field Name Length Strictly 10 characters Unlimited Unlimited 64 characters

NULL Value Support No (stores 0 or empty string) Full SQL NULL support Full JSON null support Full SQL NULL support

Coordinate Reference Any valid CRS via .prj Any valid CRS via internal registry Mandates WGS84 ( EPSG:4326 ) Any valid CRS

  • Spatial SQL Querying No Direct via SpatiaLite SQL No Limited proprietary SQL
  • 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 Y, X Y , X ). However, GeoJSON RFC 7946 strictly mandates [Longitude, Latitude] ( X , Y X, Y 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.