OS4CSAPI
End of Day 3 Report — OS4CSAPI at OGC Code Sprint 26 #11
Sam-Bolling
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Date Covered: 22 October 2025
Event: October 2025 OGC Open Standards Code Sprint
🔹 Overview
Day 3 marked the final day of OGC Code Sprint 26 and the culmination of the OS4CSAPI team’s coordinated work to exercise and validate the new OGC API – Connected Systems (CSAPI) standard across multiple open-source ecosystems. Efforts converged around verifying the stability of OpenAPI definitions, running cross-client interoperability tests, and integrating dynamic data and control stream capabilities into existing software stacks. The sprint concluded with active participation from Camptocamp, 52°North, Botts Innovative Research, and NLS Finland (Hakunapi)—each advancing independent implementations that collectively represent a complete CSAPI ecosystem, spanning OpenAPI definitions, client integrations, dynamic data services, and control stream operations.
🏗 Establishing Collaborative Spaces and Onboarding
By Day 3, the OS4CSAPI collaboration ecosystem was operating as a fully connected network of repositories, discussions, and shared tracking boards. The Org-Level Project Workspace continued to serve as the central coordination hub, now reflecting linked issues and pull requests from Camptocamp, 52 °North, Botts Innovative Research, and NLS Finland (Hakunapi). These integrations expanded visibility across both TypeScript and Python implementations, reinforcing OS4CSAPI’s role as a unifying space for Connected Systems development.
The Meta Repository remained the reference point for architectural documentation, sprint reporting, and onboarding, while the Discussions Forum supported live collaboration during the Code Sprint’s mid-phase. Contributors used these channels to exchange testing results, track schema validation findings, and align implementation strategies across teams. This day also marked a notable increase in repository cross-linking and synchronization: new items from Botts Innovative Research and NLS Finland were formally added to the workspace, giving contributors a consolidated view of progress toward each sprint goal.
Key Collaboration Links
🏛 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
Current OS4CSAPI Members (8): @Sam-Bolling | @archerdev | @EricLo-417 | @mikebotts | @SpeckiJ | @teezip | @tomkralidis | @doublebyte1
🎯 Sprint Goal 1 — Validate OpenAPI Definitions for CSAPI Parts 1 & 2
Discussion Thread: Sprint Goal #1 Feedback
Day 3 maintained focus on the ongoing validation of the official CSAPI v1.0 OpenAPI (YAML) definitions.
While no new bundle releases were issued, multiple implementation groups—including Camptocamp, Botts Innovative Research, and NLS Finland (Hakunapi)—continued using the existing YAML files from both schemas.opengis.net and the opengeospatial/ogcapi-connected-systems repository in their current development work. The previously identified packaging and reference issues—mixed relative and absolute
$refpaths, case-sensitivity mismatches, and missing schema dependencies—remain present, and implementers are still tracking these through side-by-side comparisons of the two sources. The consensus for Day 3 was to keep monitoring the next official bundle rebuild and to validate its compatibility once published.🔹 Sprint Goal 2 — Validate Client Connectivity
Day 3 featured a live demonstration by @SpeckiJ showing how a generic OGC API – Features (OAPIF) client—QGIS—can connect to and navigate an active OGC API – Connected Systems (CSAPI) server without any client-side modification or awareness of the CSAPI standard. The demonstration directly addressed Sprint Goal #2, confirming that a generic OAPIF client such as QGIS can connect to a CSAPI server as expected—discovering and exploring feature resources with no special extensions required. The session used the continuously running 52 °North CSAPI implementation built on pygeoapi and hosted at https://csa.demo.52north.org/. @SpeckiJ noted that this implementation serves both standard OAPIF and CSAPI-specific feature collections through a single, unified interface—illustrating CSAPI’s goal of extending, not replacing, OAPIF patterns. During the demonstration, QGIS successfully queried the root (
/), conformance (/conformance), and collections (/collections) endpoints; displayed entities with georeference on the map; and explored entities without georeference through the attribute-table view. QGIS handled both types seamlessly—map for georeferenced features, table for non-georeferenced ones.Findings
GetCapabilities-style probe; servers should tolerate such parameters gracefully.deployedSystems@link) appeared asNULLvalues in QGIS due to schema-inference limitations.Post-demo discussion
Two participants reported that their QGIS installations handled nested objects and arrays successfully—suggesting version or schema differences worth future comparison.
Outcome
The demo fulfilled Sprint Goal #2, confirming that a standards-compliant CSAPI server can interoperate with an unmodified OAPIF client and identifying areas to improve schema exposure and guidance.
🔹 Sprint Goal 3 — Establish Multiple Independent CSAPI Implementations
🧩 Camptocamp OGC-Client Integration (TypeScript)
Work on the CSAPI client integration within the Camptocamp
ogc-clientlibrary advanced significantly. Led through the OS4CSAPI initiative, this effort extends the TypeScript framework to support both Part 1 – Feature Resources and Part 2 – Dynamic Data of the CSAPI standard.Implementation focused on aligning the new
csapimodule with existing architecture patterns. Key accomplishments:src/ogc-api/endpoint.ts, ensuring consistent discovery and parameter handling.Once completed, this work will show that
ogc-clientcan integrate CSAPI capabilities without architectural disruption, supporting future interoperability tests with 52 °North (pygeoapi) and OpenSensorHub servers.🌐 OpenSensorHub, OWSLib, and Botts Innovative Research Ecosystem
Day 3 work across Botts Innovative Research, OpenSensorHub, and GeoPython’s OWSLib advanced the Python-side ecosystem for CSAPI. Together these projects span server, middleware, visualization, and client components.
OpenSensorHub / Botts Innovative Research
Development in OSHConnect-Python implemented and verified control streams and commands for CSAPI Part 2 (#26, #29, #30). These updates introduced control-stream discovery and refactored schema models to match current CSAPI definitions.
In the osh-viewer, new tasking interfaces were built to use these control streams: the PTZ Tasking Widget (#50) and its sub-issues for schema discovery (#62) and map-click tasking (#63) show how user interactions can drive CSAPI commands directly. A minor UI fix (#64) illustrates ongoing maintenance.
Backend work in osh-oakridge-modules expanded file and stream handling via FFmpeg, preparing OSH for dynamic-data delivery consistent with CSAPI Part 2.
OWSLib (GeoPython)
Within OWSLib, coordination with OS4CSAPI resumed to update Connected Systems support first added in 2024 (#1011). Testing fixes (#1013) established a new server endpoint and improved CI coverage, while discussion among maintainers and contributors tied these updates to broader validation goals.
Ecosystem Outlook
All related repositories were added to the OS4CSAPI Project Workspace for visibility and coordination. Once current items conclude, these Python-based components will form a connected ecosystem for CSAPI testing and validation alongside the Camptocamp TypeScript client effort.
🧭 Hakunapi
Day 3 also saw active progress within Hakunapi, maintained by NLS Finland, strengthening its foundation for next-generation OGC API implementations and future alignment with OGC API – Connected Systems (CSAPI).
Work improved developer onboarding, example datasets, and JSON Schema conformance while addressing UI and link issues:
Json.mapper()for JSON Schema compliance./itemspage for non-default CRS.seed.sql.These updates modernize Hakunapi’s workflow and examples, strengthen schema accuracy, and maintain test reliability for future OGC API and CSAPI validation activities.
🟡 Sprint Goal 5 — Prototype CSAPI with OGC Pub/Sub
Work under Sprint Goal 5 introduced publish/subscribe messaging within the Connected Systems ecosystem as a prototype for OGC Pub/Sub integration.
In OSHConnect-Python, PR #29 added support for Control Streams and Commands via MQTT, enabling systems to exchange control messages through lightweight pub/sub channels. PR #30 extended this work by refactoring control-stream and command schemas to improve type safety and discovery logic.
This integration serves as a working prototype of OGC Pub/Sub behavior in the CSAPI context, supporting bidirectional command exchange and event distribution between Systems and Clients. It provides a baseline for future transport bindings as the formal OGC Pub/Sub standard matures.
Next Steps
Extend the MQTT prototype to support data-stream subscriptions and real-time event publishing, creating a reusable pattern for live CSAPI interactions across Python and TypeScript implementations.
🧾 Summary and Next Steps
Day 3 concluded OGC Code Sprint 26, closing the event on a strong and collaborative note. Each participating team contributed verifiable progress toward independent CSAPI implementations, demonstrating the standard’s adaptability across diverse architectures and programming languages. The OS4CSAPI organization now stands as a cross-project coordination hub supporting TypeScript, Python, and Java-based initiatives. The groundwork established during this sprint positions the community to move forward into post-sprint validation, deeper integration of OGC Pub/Sub messaging, and further alignment with upcoming Connected Systems Standards Working Group discussions.
Thank you to all participants for their engagement and collaboration throughout OGC Code Sprint 26.
Beta Was this translation helpful? Give feedback.
All reactions