🧭 End of Day 1 Report — OS4CSAPI at OGC Code Sprint 26

[Sam-Bolling]

Date of Activities: October 20, 2025
Sprint: OGC Code Sprint 26
Project: Open Source for OGC API – Connected Systems (OS4CSAPI)

🧩 Overview

Day 1 of OGC Code Sprint 26 marked the first coordinated participation of the Open Source for OGC API – Connected Systems (OS4CSAPI) initiative. The activity, guided by the OGC API – Connected Systems Standards Working Group, brings together multiple open-source communities to validate and implement the OGC API – Connected Systems v1.0 specification (Parts 1 & 2). Workstreams during the first day established collaborative infrastructure, engaged new contributors, and advanced technical progress toward the sprint’s declared goals.

🏗 Establishing Collaborative Spaces and Onboarding

Prior to sprint kickoff, OS4CSAPI completed the setup of its public collaboration ecosystem:
OS4CSAPI GitHub Organization – central hub for coordination
Meta Repository – planning, onboarding, and architectural alignment
Org-Level Project Workspace – agile tracking across linked repos
Discussions Forum – transparent venue for sprint feedback

Initial Members:
@Sam-Bolling
@archerdev
@EricLo-417
@mikebotts
@SpeckiJ
@teezip
@tomkralidis

🎯 Sprint Goal 1 — Validate OpenAPI Definitions for CSAPI Parts 1 & 2

Discussion Thread: Sprint Goal #1 Feedback

Day 1 focused on collecting implementer feedback regarding the usability and structure of the official CSAPI OpenAPI (YAML) files. @EricLo-417 reported successful rendering of the Redoc documentation but noted significant friction when attempting code generation. The YAML bundle from schemas.opengis.net contained mixed relative and absolute references, case-sensitivity mismatches (e.g., SensorML vs. sensorML directories), and missing schema dependencies. In contrast, files within the opengeospatial/ogcapi-connected-systems
GitHub repository proved more functional.

@SpeckiJ responded that automated bundles are generated with each new tag release and made available under OGC’s release page. He confirmed that new bundles had just been rebuilt to resolve reference issues and suggested linking them more prominently in project documentation. This exchange highlighted the need for a consolidated and well-advertised single-file bundle to simplify validation and tooling for developers.

🎯 Sprint Goal 2 — Validate Client Connectivity to CSAPI Servers

Discussion Thread: Sprint Goal #2 Feedback

Testing on Day 1 focused on whether generic OGC API – Features clients (such as QGIS without a plugin) could connect to CSAPI servers and visualize available data. @SpeckiJ documented the test sequence between QGIS and a local CSAPI instance, noting that while root, collections, and conformance endpoints were successfully queried, issues arose with default MIME types and nested JSON arrays (e.g., deployedSystems@link). QGIS displayed these arrays as null values due to type inference limitations.

Follow-up analysis showed that QGIS requests collection schemas via /collections/{id}/schema?f=json but rejects responses that use valid JSON Schema Draft 2020-12 constructs. This finding illustrates a mismatch between the current QGIS parser and modern schema implementations. @SpeckiJ proposed two interim approaches: (1) document known limitations for QGIS users or (2) develop an optional “flattened” mapping layer to represent nested objects as simple string pairs. These findings will inform future client interoperability guidance within OS4CSAPI.

🎯 Sprint Goal 3 — Establish Multiple Independent CSAPI Implementations
Hakunapi Implementation Progress

Day 1 demonstrated measurable progress toward integrating CSAPI concepts into the nlsfi/hakunapi project. Coordination began through Issue #153 opened by @Sam-Bolling, initiating dialogue on CSAPI v1.0 adoption. Sprint participants @archerdev and @EricLo-417 provided deployment feedback and prototype support.

@archerdev developed Docker configurations for reproducible testing environments, and @EricLo-417 authored Pull Request #158, merged by @jampukka, which added a new docker directory, automated database initialization, and hot-reload functionality. These changes position Hakunapi to experiment with CSAPI entities and conformance tests.

This effort prompted creation of the OS4CSAPI discussion “Adding CSAPI to an API – Features Implementation”, featuring insights from @SpeckiJ of 52°North. Speckamp shared recommendations on handling recursive SensorML schemas, managing multi-encoding payloads, and sequencing implementation to reduce complexity. The discussion now serves as architectural guidance for future CSAPI extensions across multiple projects.

OpenSensorHub and OWSLib Implementation Progress

Parallel advances were recorded within opensensorhub/osh-core and geopython/OWSLib.

In OpenSensorHub (OSH), @tipatterson-dev submitted Pull Request #318 updating JSON-encoded Control Streams and Commands to match the latest CSAPI v1.0 schema. These changes resolved naming inconsistencies and ensured conformance with standardized property structures. The update passed all automated checks and demonstrates active alignment between OSH and Connected Systems requirements.

Within OWSLib, Issue #1013 opened by @tomkralidis addressed failing CSAPI tests caused by a retired server instance. @tipatterson-dev redirected tests to a replacement server and began resolving non-compliant elements from earlier releases, while @geographika suggested capturing mocked responses via pytest_httpserver to improve long-term CI reliability. @Sam-Bolling coordinated with contributors to extend testing to client–server interoperability validation using generic OGC API – Features clients (such as QGIS). Together these efforts reinforced the CSAPI ecosystem’s test coverage and schema stability.

Camptocamp OGC Client Implementation Progress

Client-side progress continued through the OGC Client CSAPI Implementation effort, which extends the camptocamp/ogc-client repository to support Connected Systems Parts 1 & 2. Day 1 focused on foundational documentation and test design, producing a traceable Requirements Register and Test Design Matrix linking functional requirements to formal conformance clauses. This framework establishes the basis for test-driven development and ensures compatibility with existing OGC API – EDR modules. Structural reviews of the src/ogc-api directory confirmed that new CSAPI modules will integrate cleanly within the project’s architecture.

This work represents a dedicated client-side implementation pathway that complements server developments in OSH, OWSLib, and Hakunapi, broadening the open-source landscape for Connected Systems interoperability.

🧮 Summary

Day 1 established the organizational and technical foundation for OS4CSAPI’s participation in OGC Code Sprint 26. New contributors were onboarded, infrastructure was stabilized, and meaningful progress was achieved across multiple independent implementations: Hakunapi, OpenSensorHub, OWSLib, and Camptocamp OGC Client. Each project advanced a distinct dimension of the Connected Systems standard—from schema compliance and server validation to client-side testing and tool alignment.

Collectively, these achievements validate the OS4CSAPI approach as a scalable model for bridging OGC standards development with real-world open-source implementation. The next stage will consolidate feedback from Day 1, expand interoperability testing under Sprint Goals 2 and 3, and prepare a comprehensive progress summary for the Connected Systems Standards Working Group.