Comparing changes

Add core TypeScript interfaces and types for OGC API - Connected Systems (CSAPI) Part 1 and Part 2 resources: - System, Deployment, Procedure, SamplingFeature (Part 1) - DataStream, Observation, ControlStream, Command, CommandStatus (Part 2) - Query option types for all resource collections - CSAPIResourceTypes enum mapping resource names to URL segments - ResourceLink and navigation types for @link relations

Implement CSAPIQueryBuilder class that constructs endpoint URLs for all Connected Systems resource types with full query parameter support: - 50+ methods covering systems, deployments, procedures, sampling features, datastreams, observations, control streams, commands, and command status - GET (list/byId), POST (create), PUT (update), DELETE operations - Typed query options: bbox, datetime, limit, statusCode, controlledProperty - Nested resource navigation (e.g., system -> datastreams -> observations) - Automatic URL encoding and query string assembly

Add shared utility functions and command dispatch logic: - encodeResourceId(): safe URL encoding for resource identifiers - scanCsapiLinks(): extract CSAPI link relations from API root documents - Resource-type validation and date/time parameter formatting - Command routing: dispatches command requests through the correct control-stream -> command path for Part 2 command operations

Extract typed resources from GeoJSON feature collections per the Connected Systems Part 1 standard: - constants.ts: resource-type link relation URIs, media type strings - property.ts: extract typed properties from GeoJSON feature objects - classification.ts: parse classifier/taxonomy term arrays - geojson.ts: parseResourceRef() for @link navigation, parseValidTime() for temporal extent extraction, GeoJSON-to-typed-resource mapping

Implement parsers for the OGC SWE Common Data Model JSON encoding, used by CSAPI Part 2 for observation and command result schemas: - types.ts: SWE Common interfaces (DataRecord, DataArray, scalar/range types) - components.ts: parse Quantity, Count, Boolean, Text, Category, Time components - data-record.ts: parse DataRecord structures with nested fields - data-array.ts: parse DataArray with encoding support (JSON, text, CSV) - parser.ts: top-level dispatch that routes to the correct component parser - Full test coverage for all component types and encoding formats

Implement parsers for SensorML JSON encoding (application/sml+json), used by CSAPI to describe sensor and actuator procedures: - types.ts: SensorML interfaces (PhysicalSystem, SimpleProcess, AggregateProcess) - physical-system.ts: parse physical sensor systems with position/components - simple-process.ts: parse single-step processing descriptions - aggregate-process.ts: parse multi-component process chains - parser.ts: top-level dispatch routing to the correct process type parser - errors.ts: SensorML-specific error classes - Full test coverage for all three process types and edge cases

Implement parsers for Connected Systems Part 2 dynamic data resources: - Observation parser: extract result, phenomenonTime, resultTime, datastream ref - Command parser: extract parameters, issueTime, control-stream ref - CommandStatus parser: extract statusCode, percentComplete, timestamps - Shared parseValidTime() reuse from GeoJSON module for temporal extents - Comprehensive tests covering all Part 2 resource types and edge cases

Add the format orchestration layer that ties together all individual format parsers into a unified pipeline: - response.ts: Response wrapper that normalizes parsed CSAPI responses into a consistent structure with metadata and typed content - schema-response.ts: Schema-response parser for SWE Common observation schemas, bridging schema definitions to typed format handling - formats/index.ts: Barrel module re-exporting all format parsers (GeoJSON Part 1, SWE Common, SensorML, Part 2) with pipeline orchestration for content-type-based format selection Includes comprehensive test suites for response handling, schema-response parsing, and format module exports/pipeline behavior.

Add mock API response fixtures for a sample CSAPI-enabled OGC API endpoint (sample-data-hub): - sample-data-hub.json: Root landing page with CSAPI conformance links - sample-data-hub/conformance.json: Conformance declaration including CSAPI conformance classes - sample-data-hub/collections.json: Collections listing with CSAPI-enabled collection metadata - sample-data-hub/collections/iot-sensors.json: Individual collection detail with connected systems properties These fixtures support integration tests for endpoint discovery, conformance checking, and collection-level CSAPI capability detection.

Add end-to-end integration tests that exercise the full CSAPI module stack against mock fixtures: - discovery.spec.ts: Tests for CSAPI endpoint discovery, conformance class detection, and collection-level capability enumeration - navigation.spec.ts: Tests for hierarchical system/subsystem navigation and parent-child relationship traversal - command.spec.ts: Tests for command (tasking) operations including CRUD lifecycle and status tracking - observation.spec.ts: Tests for observation retrieval with temporal filtering, format negotiation, and result parsing - pipeline.spec.ts: Tests for the full request/response pipeline including URL construction, format selection, and response parsing These tests validate cross-cutting behavior across the URL builder, format parsers, helpers, and command routing layers.

Wire the CSAPI module into the existing ogc-client infrastructure by extending 5 upstream files with CSAPI awareness: - endpoint.ts: Add CSAPI collection detection, hasConnectedSystems flag, and CSAPI query method to OgcApiEndpoint class (+136 lines) - endpoint.spec.ts: Add tests for CSAPI endpoint discovery and collection capability detection (+53 lines) - info.ts: Extend OGC API info types with CSAPI conformance classes and collection-level connected systems metadata (+31 lines) - mime-type.ts: Register CSAPI-specific MIME types (SWE Common, SensorML, SOS observation formats) in the shared registry (+64 lines) - mime-type.spec.ts: Add tests for CSAPI MIME type registration and content-type negotiation (+111 lines) This commit represents the integration point where the standalone CSAPI module (commits 1-10) connects to the existing ogc-client library architecture.

Extend the library's public API surface in src/index.ts to re-export all CSAPI types, interfaces, and enums for consumer use: - CSAPI model types (system, observation, command, collection info) - URL builder types (query parameters, filter options, pagination) - Format parser types (SWE Common, SensorML, GeoJSON Part 1, Part 2) - Response wrapper types and schema-response interfaces - Helper utility types and command routing enums This makes the full CSAPI type system available to downstream consumers via the main ogc-client package entry point.

Add editor-specific and test artifact patterns to .gitignore: - .vscode: VS Code workspace settings (editor-specific) - test-output*.txt: Temporary test output capture files

…port Phase 6 architecture refactoring — moves CSAPI from tightly-coupled endpoint method to independent sub-path module. Created: - src/ogc-api/csapi/index.ts: barrel file re-exporting 171 public symbols - src/ogc-api/csapi/factory.ts: createCSAPIBuilder() async factory function - src/ogc-api/csapi/factory.spec.ts: 2 migrated tests from endpoint.spec.ts Modified: - src/ogc-api/endpoint.ts: removed csapi() method, CSAPI imports, cache; made root and getCollectionDocument public - src/ogc-api/endpoint.spec.ts: removed 3 migrated/obsolete CSAPI tests - src/index.ts: removed ~186 CSAPI export lines (zero CSAPI references) - package.json: added ./csapi sub-path export, sideEffects: false Consumer API: import { ... } from '@camptocamp/ogc-client/csapi' One-way dependency: core compiles without CSAPI (litmus-tested). All 12 verification gates green (V1-V4, C1-C5, A4, B1-B3). Closes #120, Closes #121, Closes #122, Closes #123, Closes #124

Adds Connected Systems (CSAPI) to the supported standards list and a new section documenting the sub-path export consumer API: - What CSAPI is (OGC API Parts 1 & 2) - How to opt in via '@camptocamp/ogc-client/csapi' import - Usage example with createCSAPIBuilder() - Why a separate import path (bundle-size isolation)

@see

- Replace unsafe double cast with runtime type guard in factory.ts - Remove stale `as any` cast and outdated comment in factory.ts - Rename SystemTypeUris to SYSTEM_TYPE_RECOGNITION_VALUES (avoids shadowing the type export of the same name) - Extract shared SensorML parsing helpers to _helpers.ts (reduces duplication across aggregate-process, physical-system, physical-component) - Consolidate duplicate isRecord() type guard into shared _parse-utils.ts - Remove unused imports in SensorML parsers - Reword @see tag to use plain URL (avoids false grep matches) - Apply Prettier formatting to all source files - Expand factory tests from 2 to 6 cases - Expand endpoint CSAPI tests from 3 to 7 cases - Add live-validated Property resource fixtures and test cases

@see

Port all 20 execution passes of the Phase 7 code review cleanup plan: Phase A: #98 (@see link), #148 (redundant Record casts) Phase B: #149 (requireObject helper), #146 (parseBaseStream), #140 (paramsSchema) Phase C: #154/#155 (parseItem callback), #143 (null guard), #144 (SensorML spread) Phase D: #142 (subPath constraint), #139 (deploymentSystems), #156/#157 (remove assertResourceAvailable), #102 (nested parent IDs), #158/#159/#160 (build() wrapper, resolves #111), #150 (createCommands delegates) Phase E: #147 (URL scheme validation) Phase F: #151 (shared test fixtures) Also includes post-ST#24 fixes: #162 (..' sentinel), #163 (toArray defensive), #164 (202 JSDoc), #165 (label fallback) Source: OS4CSAPI/ogc-client-CSAPI_2 branch phase-7, commit b11f893 Validation: tsc 0 errors, 30 CSAPI suites / 1,349 tests all passing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Uh oh!

Commits on Mar 12, 2026

This comparison is taking too long to generate.

Uh oh!