activeAssets

Active Status Indicators (ASI) — a proposal for a live-status overlay on the navigation chart

Quickread information package — 4 pages · draft v0.3 · 2026-08-08. A proposal seeking a home, not a submission: no product code is allocated, and "S-1XX" is a deliberately obvious placeholder.

Fabian de Pooter — Senior productmanager maritime information services @ Rijkswaterstaat, the Netherlands · Independent maritime developer and consultant · fabian@maraton.consulting

Page 1 — What this is

The chart says what exists. Nothing on the bridge says what it is doing right now.

A berth is charted, but is it free? A lock is charted, but is it operating, levelling, or shut for the night? A bridge is charted, but will it open? Today that information lives in phone calls, VHF conversations, harbour websites and local knowledge — everywhere except the one screen the mariner is actually watching.

activeAssets is designed to close that gap with one product: Active Status Indicators. A nautical authority publishes the near-live operational status of its infrastructure — berths, anchorages, fairway sections, locks, bridges, sluices and mobile terminal infrastructure — and the navigation system (ECDIS, Inland ECDIS, PPU) portrays it as a switchable overlay, in a standardized symbology that looks the same in every port and on every waterway.

Human in control. This is the front-page rule, not a footnote. ASI states conditions; it is designed never to issue an instruction. Every hard prohibition in the product is placed there by a named human operator — never by an algorithm, never by a sensor. And the mariner's side mirrors it: the product informs the master's decision and does not make it. ASI is designed to leave the master's authority over the vessel untouched (SOLAS V/34-1). The doctrine, in one line: don't sit in the mariner's chair — give the mariner relevant, and only relevant, information for a well-informed decision.

What ASI is not:

• Not a VTS, and not a replacement for one. ASI performs only the information activity that IMO A.1158(32) clause 3.1.1 describes — and none of 3.1.2 or 3.1.3: no traffic organisation, no allocation of space, no responding to developing situations, no vessel identity, no traffic image.
• Not a warnings product. S-124 publishes the warning and its values; ASI publishes only that a state exists, and points at the authoritative source.
• Not another chart. S-101 and Inland ENC define where the assets are; S-131 (in draft) describes what they are. ASI animates what other products define — so it carries no depths, no clearances, no schedules, no vessel names.

Only the ASI. Nothing else. The system stays deliberately simple.

Deliberately universal. The design is written for coastal and inland waters alike — SOLAS and CEVNI regimes, sea locks and canal bridges, one symbology throughout.

Page 2 — What the mariner sees

Three symbols. That is the entire vocabulary.

All three carry the magenta outline of information objects. Anything the three cannot express was redesigned until it could be — the symbol count is a hard budget, because SOLAS V/15.6 makes minimising distraction on the bridge an explicit design aim.

The colours mean one thing each, everywhere. Meant to be learned once, for every asset type:

Green is deliberately absent. Green means permission everywhere in the maritime world, and ASI is designed never to grant permission. A lock door standing fully open portrays white — never green — because the exit light beside it may still show red. The product is designed to own no colour that could be mistaken for telling a vessel to go.

Interrogation, not clutter. The symbol says that something is the case. A click on it says what kind (a depth restriction, a reservation, a session). The specifics — how deep, how long, until when — stay where they already live: S-124, NAVTEX, the operator's website, the VHF working channel, all named in the service metadata. Three tiers, each answering exactly one question.

Page 3 — How it works, and how it is designed for safety

One product, one stream, one service.

• The product — a signed dataset, issued in editions, valid twelve months: every indicator's identity, position, orientation and declared update interval. Identities are never reused; a repositioned asset is a new feature (a chart-datum coordinate correction is not a reposition).
• The stream — tiny whole-state snapshots served on poll: a feature reference, a status code, and little else. A missed poll costs nothing; the next snapshot restores the whole truth.
• The service — TLS-only and certificate-gated, drafted on SECOM (IEC 63173-2; built against the review text, verification against the published edition pending) and structured per IALA Guideline G1128, with the product specification drafted as an S-100-family document (working name S-1XX). Service levels let a small authority publish only the essentials; Alpha, Bravo and obstructed are delivered at every level, always.

The datamodel is two small feature types with one join. ActiveStatusIndicator is the cartographer's: what an asset is (categoryOfAsset, 13 kinds), where it is, which way it faces. AssetStatus is the feed's: what that asset is saying right now (operationalStatus, 18 values). Neither type can carry the other's content, so a feed can never move an asset and a chart can never assert a status — the separation is enforced by the catalogue, not by convention. A new kind of asset is a new enumeration value — not a schema change, not a new symbol, not a new portrayal rule. The encoding is GML (S-100 Part 10b) for product and stream alike: producible from a database query, readable with standard tooling, no custom binary formats.

Better no data than wrong data. The second governing principle, and it does real work:

• Feed too old, value illegal for its category, parent asset not in operation, position outside its trusted area → the indicator turns grey, automatically, and recovers automatically.
• Grey is reserved for genuinely not knowing. Where a named person declares a lock, bridge or crane area obstructed, its components turn red and stay red until that declaration is lifted — nothing may pass them either, and that is known rather than unknown. Each component carries the same person's name, so one declaration is never read as several. (Propagation is deliberate per asset type: a bridge merely not in operation leaves its spans alone — their states stay true and useful.)
• The design prevents a broken sensor from closing a waterway. A failure degrades to unknown, never to prohibited. Only a person can prohibit — and when one does, it reaches everything that person shut.
• Red is asserted by a named person and cleared by a named person. A sensor may report that a berth looks free; it may never cancel what a human declared. Every prohibition in the product has a name behind it.
• Unknown future status values portray grey, not wrongly — designed so old equipment stays safe with new data.

Responsibility stays where it belongs. The publishing authority owns the published truth; responsibility is not transferable. A commercial partner may build and operate everything up to transmission — and a compliant market for exactly that is one of the goals — but the signature on the product is the authority's. Beyond transmission, portrayal is the navigation-system supplier's territory, driven by the portrayal catalogue.

Page 4 — What exists, what is open, what is asked

The following exist today, as drafts:

Open, and honestly so:

• Institutional home. The working assumption is an IHO-family product specification with the support system as a technical service per IALA Guideline G1128 — and that split is itself offered for discussion. Neither organisation has seen this proposal yet; that is what this workshop is for.
• Interoperability. The overlay ships at S-98 Level 0. Level 2 (type-based suppression and replacement) is not supported by any ECDIS today; when that support arrives, Level 2 interoperability can be considered — the design keeps that door open. Review by ECDIS makers is invited.
• Design notes. A dedicated chapter records every point where existing standards pulled in different directions and documents the choice made — as decisions, not defects.

Open in the licensing sense too. Standards documents under CC BY 4.0; tooling — producer pipeline, validators, test viewer — under Apache-2.0, with one exception: the thin QGIS plugin wrapper is GPLv3, as QGIS policy requires. An ECDIS supplier can implement ASI without paying anyone, asking anyone, or adopting anyone's stack: three SVG symbols, one small GML schema, one colour function. The bar to adoption is deliberately as low as it can be made.

What is asked of the reader:

1. Pick holes in the safety argument. The grey rules, the human-only red, the refusal behaviours — this design prefers a hard question in a workshop to a soft one at sea.
2. Judge the fit. Does a single-feature-type S-100 overlay with a G1128-structured service belong in the S-100 family — and where?
3. Bring an asset list. The categories cover what a berth-to-bridge survey of one delta produced. Other waters will produce others; the model absorbs them as enumeration values.

Drafts, test data, mockup and the full design record are available on request — fabian@maraton.consulting — including the conflicts register kept precisely so this discussion can be a sharp one.

© 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 ASI-handout.md by tools/md2html.py