Skip to content

Phase 2.8: Control Streams Methods #12

@Sam-Bolling

Description

@Sam-Bolling

Task

Implement all 8 Control Streams methods in url_builder.ts and add Control Streams method tests to url_builder.spec.ts. Control Streams is the eighth Phase 2 resource type and mirrors the DataStreams pattern (Issue #10) but for control/actuation rather than observation/sensing. It introduces the cmdFormat parameter and feasibility checking.

ROADMAP Reference: Phase 2, Task 8 — Control Streams Methods (~1.5–2 hours implementation + ~0.5 hour testing, Medium-High complexity)


Files to Create or Modify

File Action Est. Lines Purpose
src/ogc-api/csapi/url_builder.ts Modify ~55–75 added Add 8 Control Streams methods with resource validation
src/ogc-api/csapi/url_builder.spec.ts Modify ~30–40 added Add Control Streams method tests

Blueprint Reference

Follow the DataStreams methods pattern from Issue #10 (same file) — Control Streams is architecturally parallel to DataStreams. Also reference the EDR pattern in src/ogc-api/edr/url_builder.ts (562 lines) for resource validation and URL construction. The schema endpoint uses cmdFormat (analogous to obsFormat for DataStreams) and feasibility checking is a new pattern.

Scope — What to Implement

8 Control Streams Methods

Each method validates resource availability (~2 lines), builds a URL using buildResourceUrl(), appends query parameters using buildQueryString(), and returns the constructed URL string.

Collection query:

  • getControlStreams(options?: ControlStreamQueryOptions): stringGET /controlstreams with pagination, filtering, sorting

Single resource:

  • getControlStream(id: string, options?): stringGET /controlstreams/{id}

CRUD operations:

  • createControlStream(body: object): stringPOST /controlstreams
  • updateControlStream(id: string, body: object): stringPUT /controlstreams/{id}
  • deleteControlStream(id: string): stringDELETE /controlstreams/{id}

Schema retrieval:

  • getControlStreamSchema(id: string, options?): stringGET /controlstreams/{id}/schema (note: cmdFormat parameter is required per Part 2, Req 25; omitting it returns 400)

Command sub-resource:

  • getControlStreamCommands(id: string, options?): stringGET /controlstreams/{id}/commands

Feasibility checking:

  • checkCommandFeasibility(controlStreamId: string, body: object): stringPOST /controlstreams/{controlStreamId}/feasibility (tests whether a command can be executed before submitting)

Control Streams Query Parameters

Control Streams support: system, controlledProperty, datetime, executionTime, issueTime, id, uid, q, property filters, limit, offset, f, sortBy, sortOrder.

All parameters are serialised by the shared buildQueryString() helper (Issue #3). Temporal support per the Guide §6 temporal applicability matrix: datetime (validTime), executionTime, issueTime. No phenomenonTime or resultTime.

Note: The getControlStreamCommands sub-resource supports the Commands temporal parameters (issueTime, executionTime) and cursor-based pagination (cursor).

JSDoc Requirements

  • Document each method with @param for all parameters, @returns description, and usage example
  • Add @see links to OGC CSAPI Part 2 specification sections for Control Streams endpoints
  • Document the cmdFormat requirement on getControlStreamSchema
  • Document feasibility checking pattern for checkCommandFeasibility
  • Follow the JSDoc style in src/ogc-api/edr/url_builder.ts and the DataStreams methods from Issue Phase 2.6: DataStreams Methods #10

Testing Requirements

  • Extend src/ogc-api/csapi/url_builder.spec.ts (~30–40 lines)
  • Test schema retrieval (getControlStreamSchema with cmdFormat parameter)
  • Test feasibility checking (checkCommandFeasibility produces correct URL)
  • Test command listing (getControlStreamCommands)
  • Test CRUD operations produce correct URLs
  • Test resource validation — calling any Control Streams method when controlstreams is not in availableResources throws an error
  • Follow test patterns from DataStreams tests (Issue Phase 2.6: DataStreams Methods #10) and src/ogc-api/edr/url_builder.spec.ts

Scope — What NOT to Touch

Acceptance Criteria

  • url_builder.ts contains all 8 Control Streams methods listed above
  • Each method validates resource availability before constructing a URL
  • Each method uses buildResourceUrl() and buildQueryString() helpers
  • getControlStreamSchema correctly includes the cmdFormat parameter
  • checkCommandFeasibility correctly routes to /controlstreams/{id}/feasibility
  • All new methods have complete JSDoc documentation with @param, @returns, @see
  • url_builder.spec.ts contains Control Streams tests covering schema retrieval, feasibility checking, command listing, CRUD, and resource validation (~30–40 lines)
  • Existing tests still pass (npm test)
  • No lint errors

Dependencies

Blocked by: Issue #1 (Type System — provides ControlStreamQueryOptions and resource types), Issue #2 (Helper Utilities — provides encoding helpers), Issue #3 (Stub QueryBuilder — provides constructor, buildResourceUrl, buildQueryString, availableResources), Issue #5 (Systems Methods — establishes the pattern), Issue #10 (DataStreams Methods — architectural mirror)
Blocks: Issue #13 (Commands Methods — commands flow through control streams)


Operational Constraints

⚠️ MANDATORY: Before starting work on this issue, review docs/governance/AI_OPERATIONAL_CONSTRAINTS.md.

Key constraints for this task:

  • Precedence: OGC specifications → AI Collaboration Agreement → This issue description → Existing code → Conversational context
  • No scope expansion: Do not infer unstated requirements or add unrequested features
  • No refactoring: Do not rename, restructure, or "improve" code outside this issue's scope
  • Minimal diffs: Prefer the smallest change that satisfies the acceptance criteria
  • Ask when unclear: If intent is ambiguous, stop and ask for clarification

References

Read these documents before starting implementation. They are ordered by priority.

Primary References (must read)

# Document Section/Lines What It Provides
1 docs/planning/csapi-implementation-guide.md §6 Control Streams Resource Methods (lines 1750–1815) Full CRUD operations, schema operations, cmdFormat, feasibility checking
2 docs/planning/csapi-implementation-guide.md §6 Complete Query Parameter Support (lines 1927–2006) All query parameters including cmdFormat, executionTime, issueTime
3 docs/planning/csapi-implementation-guide.md §6 Query Parameters and Code Reuse (lines 720–900) Temporal applicability matrix showing Control Streams supports datetime + executionTime + issueTime
4 src/ogc-api/edr/url_builder.ts Full file (562 lines) Blueprint: method structure, resource validation, URL construction pattern
5 src/ogc-api/edr/url_builder.spec.ts Full file Blueprint: test patterns for URL builder methods
6 docs/planning/ROADMAP.md Phase 2, Task 8 (lines 278–294) Authoritative task definition, method list, test requirements

Upstream Type/Import References (files this task imports from)

# Document What to Import
7 src/ogc-api/csapi/model.ts ControlStreamQueryOptions, CSAPIResourceType (created by Issue #1)
8 src/ogc-api/csapi/helpers.ts Encoding helpers: encodeDateTime, encodeArray (created by Issue #2)

Research References (context, not required reading)

# Document What It Provides
9 docs/research/requirements/csapi-part2-requirements.md Detailed client requirements for Control Streams and actuation capabilities
10 docs/research/requirements/csapi-query-parameters.md Complete catalog of all CSAPI query parameters
11 docs/research/upstream/pr114-analysis.md Architectural patterns mirroring DataStreams for control

Specification References (for @see links and field accuracy)

# Document Use
12 OGC API - Connected Systems Part 2 (23-002) Control Streams resource definitions, schema endpoint, cmdFormat requirement (Req 25), feasibility checking
13 OGC API - Connected Systems Part 2: OpenAPI Spec Control Streams endpoint definitions — normative URL paths
14 OGC SWE Common 3.0 (24-014) Format for control parameter schemas

Convention Quick Reference

Rule Example
Use .js extension for relative imports import { X } from './file.js'
Use import type for interfaces/types import type { Y } from './model.js'
Three-tier hierarchy: import from lower tiers only shared → ogc-api → csapi
Named exports for types and utilities export interface Z { ... }
as const arrays for enum-like values export const XTypes = [...] as const
HTTP mocking: globalThis.fetch = jest.fn() Never use nock, msw, or other libraries
Meaningful tests only Verify behavior, not that code runs without throwing

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions