S-1XX — Active Status Indicators

Draft Product Specification — Edition 0.1.0

DRAFT FOR DISCUSSION — 2026-08-07. No IHO product code allocated; S-1XX is a deliberately obvious placeholder. Clause structure follows S-100 Ed 5.2.1 Part 11 clause 11-3: mandatory sections (a)–(j) all present; conditional sections Data Maintenance, Portrayal and the Feature Catalogue included because this product requires them. Sections marked ◪ are skeleton; sections with text are drafted from the recorded design contract and can be read for review.

1 Overview (11-4)

1.1 Introduction. S-1XX publishes Active Status Indicators (ASI): the near-live operational status of berths, anchorages, fairway sections, locks, bridges, sluices and mobile terminal infrastructure, as a switchable overlay on ECDIS, Inland ECDIS and PPU. The product models indicators, not assets: the assets are published by S-101, Inland ENC and S-131 (in draft). S-1XX is their dynamic counterpart — the static products define the assets; S-1XX supplies their dynamic status.

1.2 Purpose. To give the mariner relevant — and only relevant — information about the current condition of infrastructure ahead, so that the mariner can make a well-informed decision. The product states conditions; it never issues an instruction, and nothing in it impedes the master's authority over the vessel (SOLAS V/34-1). Two governing principles apply to every rule in this specification: the product does not sit in the mariner's chair, and better no data than wrong data.

1.3 Product composition. A complete S-1XX service consists of:

• the product — a signed dataset declaring the indicators, their identities, geometry, orientation, update intervals and aggregations; issued in editions, valid twelve months;
• the status stream — small whole-state snapshots served on poll, carrying only operationalStatus and a small set of companion attributes (§7.4);
• service metadata — endpoint, polling limits, service levels, and where the authority publishes specifics (S-124, NAVTEX, operator URL, VHF).

1.4 References. ◪ (S-100 5.2.1; S-98 2.0.0; S-97 1.1.0; IEC 63173-2 (SECOM); IALA G1128; IMO A.1158(32); SOLAS V; International Code of Signals.)

1.5 Terms. ◪ (Reuse S-100 Part 1 + A.1158(32) clause 2 definitions verbatim; new terms only: Active Status Indicator, asset, invalidation, exception-only indicator, declared home position.)

2 Specification scopes (11-5)

One scope: general. S100_SpecificationScope = 1.

3 Dataset identification (11-6)

◪ Fields per Part 10b DatasetIdentificationType. productIdentifier = S-1XX (placeholder); datasetPurpose = base | update. Producer codes per the S-62-style register of the issuing authority's domain.

4 Data content and structure (11-7)

4.1 Application schema — two types, and the split is the point.

AssetStatus references the indicator it reports on by that indicator's identifier, which the producer issues and never reuses (§4.5). The identifier is therefore the whole of the join between the two models.

4.1.1 Neither type may carry the other's content. A producer cannot author an operational status, because the type they author has no attribute to put one in; a feed cannot rename an asset or move it permanently, for the same reason. What was a convention is now structural — the catalogue makes the invalid case unsayable rather than merely forbidden, and it is checkable in the Feature Catalogue itself rather than only in the data.

4.1.2 The overlay rule. A reading system holds the most recent AssetStatus for an indicator as a transient overlay on the persistent product:

• where an AssetStatus supplies a value, it prevails;
• where it supplies none, or where it is no longer trusted (Portrayal Guide clause 6), the product's own value applies;
• where the product has no value either — as for operationalStatus, which the product never carries — the indicator has no trusted state and portrays grey.

The kind of asset is stated by categoryOfAsset (13 values); the live condition by operationalStatus (18 values). The complete Feature Catalogue is ASI_FeatureCatalogue_0.1.0.xml; the value lists and their meaning groups are reproduced in Annex A.

4.2 Rationale for a single feature type. The phenomenon this product publishes is the indicator. Modelling locks, bridges and berths again — which S-101 already carries and draft S-131 will — would duplicate material that other specifications describe. A new kind of asset is therefore an enumeration value, not a schema change.

4.3 Conditional domains. The operationalStatus values permitted for each categoryOfAsset, and the permitted parent/component category pairs of AssetAggregation, are defined in Annex B as tables and delivered as executable validation rules (Schematron and the S-1XX auditor). A dataset violating Annex B is invalid; a stream value violating Annex B shall be treated by the reading system as no trusted data.

4.4 Aggregation. AssetAggregation (roles theCollection / theComponent, S-100 whole-part pattern): lock → basin, gates, spans; bridge → spans; MTI area → MTI. A span indicator — opening or fixed — is a component of exactly one bridge or one lock, never both. A sluice is standalone.

Both kinds of span take the same parentage, and deliberately so: a lock commonly carries a fixed road crossing over its chamber, and the two differ only in whether the deck moves. A rule that let an opening span belong to a lock while its fixed sibling could not would have made an ordinary arrangement unencodable.

4.4.1 The reference is carried by the component, and points at the collection. Each component holds exactly one reference, in the role theCollection, whose value is the collection's own feature identifier. A collection holds no references and needs no identifier of its own beyond the one it already has: there is no separate group or collection code.

Three reasons this direction rather than the reverse:

• It is single-valued. A component belongs to exactly one collection, so the reference is one scalar. A collection has many components, so the opposite direction needs a repeating element in GML and a link table in any relational form — the same fact, encoded more expensively.
• It makes the exclusivity rule structural. A span belongs to a bridge or a lock, never both is enforced by the field's own cardinality. Encoded on the collection, nothing would stop two collections both listing the same span, and the rule would need an auditor to catch what the model should have made unsayable.
• A new component is one new feature. Adding a gate does not modify the lock. That matters for edition management: the change is confined to the thing that changed, and the collection's record is untouched.

A shared group code carried by every member — collection included — would express a set, not a hierarchy: it says these features belong together but not which of them is the whole. The parent reference says both, using an identifier that already exists.

4.5 Identity. Feature identifiers are never reused and never re-bound to another location. A repositioned asset is a new feature in a new edition; the old identifier is retired permanently. A chart-datum coordinate correction is not a reposition.

4.6 Geometry. Point, curve (fairway section) or surface (anchorage, MTI area). Explicit geometry only; linear referencing is not used (Part 10b excludes it; distance marks charted by ENC and Inland ENC give the mariner the kilometre frame). All coordinates WGS 84.

Geometry is static for every category except mobileTerminalInfrastructure, whose product geometry is the position the asset occupies when it is not working — its parking or stowage place — and is overlaid by the stream while a trusted live position exists (§4.1.2, §7.4.3).

There is no separate home-position attribute. The product's geometry is the home position: a cartographer placing a mobile asset has only one sensible point to place it at, and that point is where it sits when idle. The fallback therefore needs no declaration of its own — when the overlay lapses, the product shows through, which is the general rule of §4.1.2 rather than a special case.

4.7 Movement buffer. Declared once in the dataset header for the whole product, not per feature — see §13.1. It is not an attribute of the feature type.

5 Coordinate Reference Systems (11-7.3)

EPSG::4326, per the S-100 GML profile requirement for a well-known, pre-defined CRS.

6 Data quality (11-8)

◪ Per S-97 Part C. Product-specific measures: identifier stability across editions (L-6 checker); home-position containment and its ground-truth confirmation at commissioning; orientation ground-truth confirmation at commissioning (the test viewer emits a commissioning record: named person, date, physical operation — see §10.4); declared-vs-measured update interval conformance.

7 Data capture and encoding (11-9)

7.1 Captured per the Encoding Guide (separate volume). Producer-facing derivations are recorded there and do not appear in mariner-facing documents.

7.2 Orientation. orientationValue is the main direction of flow (downstream), declared once by the cartographer. Tidal structures: downstream is always seawards. Where no obvious downstream direction exists, the producer shall ensure the encoded direction equals the actual direction of flow at the structure, confirmed at commissioning.

7.3 Where a mobile asset is placed in the product. An MTI's product geometry shall be the place the asset physically occupies when it is not working — its parking or stowage position — and shall lie within its MTI Area (validated). It is a real, identifiable location, confirmed against the structure at commissioning like orientationValue, not a point chosen to be harmless.

It is the drawn position whenever no live position is trusted and it remains a plausible estimate: before any report has been received, and while the MTI Area is invalidated. It is not used once the asset has reported from outside its area — see the Portrayal Guide clause 8.4.

7.4 The stream. Whole-state snapshots (a missed poll has no effect; a missed message would corrupt the view). Fields: feature reference, operationalStatus, directionSense (with levelling and flowing only — see §7.4.4), geometry for mobile terminal infrastructure (§7.4.3), operationalSubStatus (complex and repeatable — subStatusType, plus subStatusValue where the type calls for one; §7.4.5), timestamp as a thematic attribute, human attribution where §8.2 requires it. No other fields are permitted.

7.4.1 Movement of mobile terminal infrastructure is not transmitted. No movement state and no bearing appear in the stream. The reading system derives both from consecutive positions, against the movement buffer declared in §4.7, by the normative rules of the Portrayal Guide clause 5.5. A source system therefore cannot report movement incorrectly, because it does not report it at all.

7.4.5 The sub status carries the lock session identifier. operationalSubStatus is complex and repeatable: each entry states a subStatusType, and an entry may carry a subStatusValue. At present only type 5 lockSession does so, holding the session identifier allocated by the authority. subStatusValue shall not be used to carry the magnitude of a restriction.

It is complex because it repeats. A feature may assert several sub statuses at once, so a value held in a separate field could not say which of them it qualified; nesting it inside its own entry removes the question.

Stating a session identifier does not breach §1.2's rule against carrying values. What that rule protects against is publishing a specific — a depth, a speed — that an authoritative publication already owns, creating two sources that can disagree. A lock session number has no second source: the authority allocates it and it exists nowhere else. The rule is therefore that the product never carries a value another publication owns; an identifier it issues itself is its own to state.

7.4.4 No direction is declared for a moving barrier. directionSense accompanies levelling and flowing — the movement of water — and is not sent with moving. A lock gate or opening span in motion reports only that it is moving.

A direction of leaf travel cannot be expressed in the horizontal plane for most gate types: a lift gate moves vertically, and a mitre gate swings two leaves apart in opposing arcs. Requiring a direction would oblige producers to invent one wherever the mechanism has none, and the mariner's question — whether the gate is yet passable — is answered by the status without it.

7.4.3 The position of mobile terminal infrastructure is carried as geometry, not as an attribute. A snapshot conveys the current position of such a feature by supplying its geometry, retaining the feature identifier issued in the base dataset (Part 10b 11.5). No latitude or longitude attribute is used. Snapshots carry geometry only for features whose geometry can change; every other feature takes its geometry from the product, where it is fixed.

Encoding a position as a pair of real attributes when the format has a native geometry type puts the same fact in two vocabularies. As geometry it is read by any conformant GML client without product-specific code, and it can be filtered spatially by a server — which is what a subscription scoped to the mariner's viewport requires.

7.4.2 Position is suspended while a mobile terminal infrastructure feature reports idle. Its position is held at the last value received before that state, and no movement is derived from it, until the feature returns to service (Portrayal Guide 5.5.9). A suspended position is a normal operating condition and shall not be portrayed as absence of trusted data.

7.5 Update intervals. Declared per feature in the product. Indicative: alpha/bravo/obstructed instant; lock gate 5 s; basin 10 s; mobile terminal infrastructure 10 s; berth/anchorage/fairway 60 s; sluice 300 s. The polling interval offered to a client shall never be shorter than the shortest declared update interval it covers; polling limits are stated in service metadata.

The interval for mobile terminal infrastructure is constrained by portrayal, not only by rate of change: the chevron is withdrawn after five consecutive stationary reports (Portrayal Guide 5.5.4), so the interval shall be short enough that five of them is an acceptable lag.

8 Data integrity rules

8.1 One write path. Every status change, including the authority's own staff, enters through the same authenticated API, attributed to a named person or a declared source system.

8.2 Human assertion ("red is human"). obstructed shall only be asserted by a named human operator and shall never be set or cleared by automation. A sensor may set a permissive state; it shall never clear a human-asserted state. A failed feed degrades to no trusted data, never to obstructed.

8.3 Sensors. Sensor-derived indicators declare method, latency and limitations in the Source Level Declaration; ground truth is verified at commissioning (S1–S7).

9 Data maintenance (11-10)

9.1 Editions replace; numbered update datasets add or replace features but never delete (Part 10b 11.5); a withdrawn asset requires a new edition. Update datasets retain base-edition GML identifiers, which the identifier rules of §4.5 already require.

9.2 Product validity twelve months from issue. Transmission is not terminated at expiry but ends at the first system switch-off after it. The server refuses service on: invalid certificate, expiry, or an edition outside the allowed list.

10 Portrayal (11-11)

10.1 The Portrayal Catalogue implements ASI_PortrayalGuide (separate volume): three symbols, fill a pure function of operationalStatus, chevron presence-and-direction, flags essential, grey for no trusted data, green and yellow reserved.

10.2 Interoperability: S-98 Level 0 (overlay) always. Level 2 (type-level suppression and replacement) is not supported by any reading system today; Level 2 operation can be considered when that support arrives. Suppression sets: ◪.

10.3 Palette conformance, symbol vocabulary and status domains are auditable (R36a/b/c); the tooling includes a catalogue conformance checker.

10.4 The test viewer renders through the same portrayal path as an ECDIS — same catalogue, same rule engine, same symbols — and shows the raw received value beside the portrayed symbol, endpoint liveness and a timestamped log; it can emit the §6 commissioning record.

11 Data product format (11-12)

GML per S-100 Part 10b, for both the product and the stream — one schema, one parser, one validator. Grounds recorded: S-97 B-13-1 places small datasets delivered via messages and web services in the GML column; production complexity low; every response is a complete static snapshot, so the profile's exclusion of dynamic features never applies. Timestamps are thematic attributes (no ISO 19108 temporal primitives). File extension .GML.

12 Data product delivery (11-13)

12.1 Product datasets: exchange set with signed catalogue metadata (Part 17), X.509 signatures. 12.2 Stream: SECOM-conformant service (IEC 63173-2; drafted against the 2019 review text, verification against the published edition pending — see the Service Technical Design) — Get/GetSummary on poll; access control via RequestAccess/AccessNotification. VDES is opted in as a bearer where available. Service levels (essential / standard / full) per service metadata; alpha, bravo and obstructed are essential information delivered at every level. 12.3 Client signal discipline: product state green/orange/red (current / update available / not accepted) and feed state live / latency over limit / disrupted are mandatory client indications.

13 Metadata (11-15)

◪ Per Part 4a: discovery metadata, plus service metadata carrying endpoint, polling limits, service levels, and the authority's authoritative channels for specifics (S-124, NAVTEX, operator URL, VHF working channel).

13.1 Movement buffer (product header). The dataset header shall declare a single movement buffer, in metres, applying to every mobileTerminalInfrastructure feature in the product. Default 5 m. It is the threshold against which a reading system derives movement from consecutive geometries (Portrayal Guide clause 5.5). The declared value shall exceed the positional uncertainty of the least precise mobile source in the product — checkable, and therefore part of the validation set (§9).

Where that cannot be achieved the portrayal does not degrade toward silence: movement is portrayed (Portrayal Guide 5.5.11), because for an object near a vessel's track the tolerable error is the one that over-warns. The requirement stands nonetheless — a buffer far below the source's uncertainty produces a chevron that is permanently lit, which a mariner learns to disregard.

It is declared once per product rather than per feature because it is not a property of any asset. A crane does not have a movement buffer; it has a position. The buffer is a parameter of how a reading system interprets successive positions, so it belongs with the product's other reading parameters and not in the Feature Catalogue, which describes what things are.

The practical cost of one value for all is small. Mobile terminal infrastructure moves at about walking pace, so at the 10 s interval of §7.5 it advances roughly 14 m between reports — further than any plausible buffer. A buffer sized for the least precise source therefore still detects movement on the first report for every source; what it loses is sensitivity to motion slower than walking, and it loses it uniformly and predictably.

Annex A — categoryOfAsset and operationalStatus value lists (normative)

As ASI-enumeration.md §1–§2 / the Feature Catalogue. ◪ (generate from FC at layout time — single source, no divergence)

Annex B — Conditional domains (normative, delivered as executable rules)

As ASI-enumeration.md §3 plus the parent/child pair table.

Annex C — Test dataset and scenario (informative)

ZZASI001_base.gml + SCENARIO.md T0–T9 with expected portrayal per step.

Annex D — Design notes (informative)

The information-package Design Notes chapter accompanies the specification: decisions made where standards conflicted, recorded as decisions, not defects.

© 2026 W.D. de Pooter · Independent marine consultant and developer · fabian@maraton.consulting Licensed under Creative Commons Attribution 4.0 International. SPDX-License-Identifier: CC-BY-4.0

activeAssets — rendered from draft/ASI_ProductSpecification_0.1.0.md by tools/md2html.py