Parent Issue

Split from #100 — assertResourceAvailable() is overly strict for per-ID methods — blocks valid URL construction for nested resources.

This is Part 2 of 2. See also: #156 (Part 1 — Systems, Deployments, Procedures, SamplingFeatures).

Scope — Part 2 Only

Remove this.assertResourceAvailable(...) from per-ID methods for the remaining 5 resource types. These are the Part 2 resources + Properties — the group most commonly impacted by the original bug since Part 2 resources (datastreams, observations, controlStreams, commands) are often only available as nested paths under systems.

Resource Types in This Part

File to Modify

Pattern

Same as Part 1. Each per-ID method changes from:

getDataStreamSchema(id: string, options?: QueryOptions): string {
  this.assertResourceAvailable('datastreams');  // ← Remove this line
  return this.buildResourceUrl('datastreams', id, 'schema', options);
}

to:

getDataStreamSchema(id: string, options?: QueryOptions): string {
  return this.buildResourceUrl('datastreams', id, 'schema', options);
}

Which Methods to Change (39 deletions)

Properties (5): All methods matching get/update/deleteProperty* that take an id parameter. Examples: getProperty(), updateProperty(), deleteProperty(), getPropertyDataStreams(), getPropertyControlStreams().

Datastreams (9): All methods matching get/update/deleteDataStream* that take an id parameter. Examples: getDataStream(), updateDataStream(), deleteDataStream(), getDataStreamSchema(), getDataStreamObservations(), createObservation(), etc.

Observations (7): All methods matching get/update/deleteObservation* that take an id parameter. Examples: getObservation(), updateObservation(), deleteObservation(), getObservationDatastream(), getObservationSystem(), etc.

ControlStreams (9): All methods matching get/update/deleteControlStream* that take an id parameter. Examples: getControlStream(), updateControlStream(), deleteControlStream(), getControlStreamSchema(), getControlStreamCommands(), createCommand(), etc.

Commands (9): All methods matching get/update/deleteCommand* that take an id parameter. Examples: getCommand(), updateCommand(), deleteCommand(), getCommandStatus(), updateCommandStatus(), getCommandResult(), cancelCommand(), etc.

Which Methods to KEEP Unchanged

All list/create methods (no id parameter) retain their assertResourceAvailable() guard:

• getProperties(), getDataStreams(), createDataStream(), getObservations(), getControlStreams(), createControlStream(), getCommands()

What NOT to Touch

• ❌ Systems, Deployments, Procedures, SamplingFeatures — already done in Part 1 (#100 Part 1: Remove assertResourceAvailable from per-ID methods — Systems, Deployments, Procedures, SamplingFeatures (33 methods) #156)
• ❌ List/create methods (no id parameter) — keep their guards
• ❌ assertResourceAvailable() definition itself
• ❌ buildResourceUrl() — no changes needed
• ❌ Any file outside url_builder.ts
• ❌ Test files — existing tests should pass unchanged

Acceptance Criteria (Part 2)

• 39 this.assertResourceAvailable(...) calls removed from per-ID methods for Properties, Datastreams, Observations, ControlStreams, Commands
• 7 list/create methods for these 5 types still have their assertResourceAvailable() guards
• Combined with Part 1: zero assertResourceAvailable() calls remain in any per-ID method across all 9 resource types
• Only 15 assertResourceAvailable() calls remain total (all in list/create methods)
• tsc --noEmit — zero errors
• npm test — all tests pass
• npm run lint — zero errors

Dependencies

Blocked by: #156 (Part 1 — must be completed first so we don't double-count)
Blocks: #145 (build() wrapper), #102 (nested parent IDs)

References

• [SPLIT] assertResourceAvailable() overly strict for per-ID methods → #156 + #157 #100 — parent issue with full analysis, cross-server findings, OGC spec context
• #100 Part 1: Remove assertResourceAvailable from per-ID methods — Systems, Deployments, Procedures, SamplingFeatures (33 methods) #156 — Part 1 (Systems, Deployments, Procedures, SamplingFeatures)
• CSAPIQueryBuilder.assertResourceAvailable(): url_builder.ts ~L320–327
• buildResourceUrl() fallback behavior: url_builder.ts ~L256–273
• Phase 7 Scope & Split Assessment

Operational Constraints

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

Upstream Isolation Constraint

Per the upstream maintainer's comment on PR #136: url_builder.ts is within src/ogc-api/csapi/ — purely internal to the isolated CSAPI module.