1. What UniversalHydroTide Is

UniversalHydroTide (also presented in the application as Universal Hydrographic Tide) is a Windows-based hydrographic water-level and vertical-reference platform designed to solve a problem that appears simple until a survey has to be delivered: how to take tide, water-level, GNSS, pressure, geoid, datum, model and survey-timing information from many different sources and turn it into one defensible, traceable vertical correction that can be used by hydrographic processing software without silently changing the physics from one export to another.

The core design is deliberately source-neutral and target-neutral. A CHS observation, a NOAA prediction, an SMHI RH2000 series, an IOC/SLSMF near-real-time feed, a local contractor CSV, a pressure-gauge record, a gridded tidal model or an ERS/GNSS vertical solution is not converted directly into a vendor tide file. Instead, every accepted source is normalized into a Universal Tide / Vertical Data Model (UTVDM). Hydrographic calculations, datum transformations, temporal processing, spatial interpolation, uncertainty propagation and quality-control decisions are performed centrally. Only after the master solution passes the required gates can one or more target exporters serialize that same solution for downstream software.

That separation is important. It prevents the CARIS exporter, Qimera/QINSy exporter, HYPACK exporter or any other adapter from inventing a different tide solution. The exporter is allowed to change representation—such as file syntax, field order, time encoding, units or sign convention—but not the underlying hydrographic answer.

2. The Problem the Software Is Designed to Solve

Hydrographic survey projects routinely combine information from systems that were never designed to share one common vertical language. Water-level services may publish observations in a local chart datum, national height system or relative gauge zero. Predictions may use another vertical reference. GNSS heights are ellipsoidal. Geoid models relate ellipsoidal and orthometric heights but are not themselves Chart Datum. Survey software packages expect different tide-file structures. Timestamps may be UTC, local civil time, GPS time or a proprietary epoch. A processing mistake in any one of these areas can shift an entire bathymetric surface.

UniversalHydroTide addresses this by making time basis, vertical datum, horizontal CRS, reference frame, epoch, units, sign convention, spatial validity and uncertainty explicit data rather than hidden assumptions. Ambiguity that could alter the hydrographic result is treated as a blocking condition, not as something the program silently guesses.

• No silent inference of vertical datum, timezone, sign convention, reference frame or coordinate epoch where the choice can change the survey result.
• No direct Provider-A-to-Software-B conversion path that bypasses the common physical model.
• No modification of the immutable source record; transformations are applied to versioned working datasets.
• No target exporter is allowed to recalculate tide physics.
• No release of a dataset that fails mandatory datum, coverage, uncertainty, schema, signature or round-trip checks.

3. End-to-End Processing Architecture

A typical UniversalHydroTide job is a gated workflow rather than a single file-conversion command. The project first freezes the survey requirements, then acquires and fingerprints the inputs, normalizes them into the UTVDM, performs the physical and geodetic calculations, checks temporal and spatial coverage, propagates uncertainty, creates a versioned master solution and finally produces target-specific outputs plus evidence.

In practical terms, the workflow is: project definition → source acquisition → source fingerprinting → parsing → preservation of original data → time/unit/sign normalization → datum/CRS/reference-frame checks → tide or ERS processing → QC → interpolation/zoning → uncertainty → MBES coverage verification → immutable master solution → one or many exporters → round-trip validation → approval/version evidence → delivery package.

• Project requirements: target vertical datum, time basis, horizontal CRS/reference frame, survey order/tolerance, target applications and required outputs.
• Source fingerprinting: provider, file/API endpoint, version, retrieval time, licence/attribution, checksum and adapter identity.
• Normalization: canonical UTC, SI metres, explicit positive-up internal water-level sign, datum and geodetic metadata preserved.
• Processing: conventional tide, harmonic/modelled tide, pressure-derived water level, ERS/geoid/SEP, or parallel independent solutions.
• Quality gates: temporal, signal, datum/geodesy, spatial, cross-source, MBES coverage, uncertainty and output conformance.
• Delivery: target tide files, master neutral dataset, QC report, provenance, standards products such as S-104, and optional vertical-model surfaces.

4. Input Sources and Data Ingestion

The ingestion layer is adapter-driven. Known providers have native adapters with their own station identifiers, parameter rules, date-range logic, datum semantics, QC-field mapping and tests. Unknown or client-specific tables can be handled through a generic mapper that requires explicit field mapping instead of guessing the meaning of a column.

The architecture accepts observed, predicted, forecast and modelled water levels; harmonic constituents; pressure-gauge observations; GNSS/ERS trajectories; geoid, quasigeoid and separation models; local tide files; and survey timing/track information used to prove that corrections cover the actual MBES acquisition window.

• Generic files: CSV, TXT, ASC, DAT and configurable delimited/tabular data.
• Spreadsheet and structured sources: XLS/XLSX, JSON and XML where the installed adapter supports the schema.
• Hydrographic and scientific data: TID/vendor tide formats, HDF5/S-104 products, NetCDF/gridded sources where a qualified reader is available.
• Connected services: REST APIs and other registered network sources; responses are cached with retrieval metadata and checksums.
• Sensor-oriented sources: pressure/water-level telemetry and GNSS feeds can be preserved as immutable acquisition records before reduction.
• Model resources: global/national geoid, quasigeoid, hydroid/SEP and tide-model resources are governed by geographic validity, datum/reference-frame identity, version and licence metadata.

5. Live Provider Registry and Provider Qualification

The GUI exposes a Global Live Provider Registry rather than hiding providers that are not yet ready. Each entry carries a readiness state, machine-access method, authentication requirement, vertical-datum policy, licence requirement and qualified capability. This is a significant safety feature: a provider can be visible to the operator while retrieval remains disabled until the software has a qualified parser, authentication route and datum contract.

The current codebase contains native or qualified adapter work for Canada (CHS/IWLS), the United States (NOAA CO-OPS), Sweden (SMHI), Denmark (DMI), the United Kingdom Environment Agency tide-gauge route, Lithuania/Meteo LT, Estonia hydrology/sea-level sources and UHSLC. IOC/UNESCO with VLIZ Sea Level Station Monitoring Facility (SLSMF) is integrated through a credential-gated registry path; its near-real-time/latest route is treated separately from broader history/research acquisition so that missing datum/operator evidence cannot be mistaken for a production-ready hydrographic correction.

A provider PASS requires more than HTTP success. The intended chain is real fetch → parser → UTVDM normalization → QC → datum checks → export path. Upstream outage, empty response, bad datum, parser failure, TLS failure, licensing restriction or export failure remains a real failure rather than being converted into a green status.

• • CHS / Canadian Hydrographic Service: station resolution, observations/predictions and provider-specific policy controls.
  • NOAA CO-OPS: observations/predictions and station-driven retrieval in metric/authorized datum modes.
  • SMHI: RH2000 support including recent data and archive/recent merging for history-to-present workflows when the provider advertises the required series.
  • DMI: observed sea level with explicit DVR90 semantics; chronology is normalized client-side when provider ordering is unsuitable.
  • UK Environment Agency: tide-gauge retrieval with chronology and duplicate handling under the adapter rather than relying on server sort assumptions.
  • UHSLC and selected Baltic/European services: research/history adapters with provider-specific time/datum handling.
  • IOC/SLSMF: credentialed global monitoring route with provenance and relative/unknown datum safeguards; full hydrographic datum promotion remains gated by station/operator evidence.

6. Operator Workflow in the Desktop GUI

The desktop application is built around operator workspaces rather than a developer console. The main navigation exposes Dashboard, Project, Local Sources, Live Providers, Geoid & Height, Results, Conformance, Settings and Production. Provider controls are dynamically constrained by the selected adapter, so irrelevant fields can be disabled while required datum, period, cache and credential inputs remain visible.

The GUI also keeps an activity/results area visible during operations. This is not just a convenience log: it provides an operator-facing audit trail showing provider, operation, context, result, duration and message. The same philosophy extends to search results, diagnostics, conformance output and production artifacts.

7. Universal Tide / Vertical Data Model (UTVDM)

The UTVDM is the central abstraction that allows unlike sources to be processed by one core engine. Every record retains both source-native information and normalized working values. This means the software can answer not only “what water level was used?” but also “where did it come from, what did it originally say, which datum did it use, what transformations were applied, and what uncertainty was attached at each step?”

Typical UTVDM fields include immutable record identity, source provider and endpoint/file, source checksum and version, retrieval time, station identity, coordinates, CRS, reference frame, coordinate epoch, original timestamp and timezone, normalized UTC timestamp, original and normalized water level, units, original sign convention, source and target vertical datums, transform identifier, data type, provider and internal QC states, standard uncertainty, interpolation status, processing version and ordered audit chain.

8. Time, Units and Sign Convention Engine

Time mistakes are among the most damaging errors in tide processing because a perfectly valid water-level curve can be applied at the wrong epoch. UniversalHydroTide stores UTC internally while preserving the original timestamp and timezone interpretation. The time layer is designed for UTC, local standard/daylight time, named IANA time zones, GPS time, Unix time, Julian Date and Modified Julian Date, with versioned leap-second handling.

Vertical values are normalized to SI metres internally. The original unit and sign convention remain part of provenance. The canonical water-level sign is positive upward relative to the defined datum; target adapters apply explicit output sign and unit transformations only at serialization time. International foot and legacy US survey-foot distinctions are not collapsed into one ambiguous “feet” setting.

9. Datum Transfer, CRS, Reference Frame and Epoch Safety

A water level is not hydrographically meaningful without a reference. UniversalHydroTide represents vertical conversion as a transformation path with a source datum, target datum, horizontal CRS/reference frame, coordinate epoch, transformation model/grid, geographic validity and uncertainty. A transformation outside its area or epoch, or between incompatible frames without an approved path, is blocked.

The vertical graph/solver supports direct offsets, gridded transformations and multi-step paths. The calculation engine can solve forward and inverse paths, carry uncertainty, and expose the exact route used. This is the foundation for safe transfer between gauge zero, Chart Datum, LAT, MLLW, MSL, national height systems, ellipsoidal reference surfaces and project-specific vertical references.

A central rule is that a geoid is not treated as Chart Datum. Converting an ellipsoidal GNSS height to a hydrographic chart datum requires a valid ellipsoid-to-Chart-Datum separation surface (SEP/hydroid) or an explicitly justified construction procedure.

10. Tide-Gauge, Pressure and Physical Sensor Reduction

Observed gauge data can carry provider QC flags, but UniversalHydroTide performs its own independent QC as well. Gauge-zero changes, benchmark transfer, calibration records and datum shifts are treated as explicit operations with evidence rather than hidden corrections.

For pressure-derived water levels, the software architecture includes atmospheric/barometric correction and seawater-density treatment. The development path also includes TEOS-10-aware density handling so that pressure is not naively divided by a fixed density in situations where salinity, temperature or gravity treatment materially affects the result. Sensor metadata, calibration state and uncertainty are carried into the propagated solution.

11. Harmonic Analysis, Prediction and Tidal Datums

The harmonic subsystem is more than a curve-fitting utility. The current standards core includes least-squares harmonic analysis, a controlled constituent registry, principal astronomical V/f/u treatment, authority profiles, robustness gates, production prediction, residual/total-water-level composition and a tidal-datum solver with epoch/authority/uncertainty metadata.

A typical production analysis requires a minimum record length selected for the constituent set and survey requirement. The engine reports observations used, record duration, fit/conditioning information and solved constants. Predictions are generated from a defined constituent/astronomy profile rather than an opaque vendor routine. Where observed and predicted series coexist, the non-tidal residual is retained instead of overwriting either source; total water level can then be composed from tide plus residual/surge under an explicit model.

• Least-squares harmonic analysis and constituent solution.
• Principal tidal constituent catalogue and astronomical argument treatment.
• Authority/profile identity so constituents and conventions are not mixed silently.
• Robustness and external-acceptance checks for ill-conditioned or insufficient records.
• Production tidal prediction with uncertainty.
• Observed minus predicted residual/surge and total-water-level composition.
• Tidal-datum solver with explicit epoch, authority and uncertainty.

12. Spatial Tide, Zoning and Gridded Surfaces

A single station is not always adequate for a survey corridor. UniversalHydroTide therefore includes spatial logic for station selection, zoning and track-aware correction. The spatial engine governs zone topology, station influence, boundary crossing, track segmentation, continuity and gap handling so that a vessel does not unknowingly jump between incompatible corrections.

For gridded surfaces, the software includes interpolation, NoData and boundary governance, uncertainty propagation and multi-surface colocation/resampling. Sea-surface-topography (SST) and mean-dynamic-topography (MDT) surfaces are treated as governed vertical resources with reference frame, epoch and validity metadata, not as anonymous rasters.

13. Geoid, Quasigeoid, SEP/Hydroid and Ellipsoidally Referenced Surveying (ERS)

UniversalHydroTide supports a second vertical-referencing route alongside conventional tide correction: ellipsoidally referenced surveying. In the ERS route, a GNSS trajectory is combined with a geoid/quasigeoid and a hydrographic separation surface that relates the ellipsoid to the project Chart Datum or other target vertical reference.

The geoid/vertical-resource framework is designed to manage global and national models, local gravimetric surfaces and hybrid surfaces fitted to independent control. Model identity, file fingerprint, spatial extent, resolution, epoch, reference frame, licence and uncertainty are part of qualification. A resource that does not cover the project point or does not pass integrity checks is not silently substituted.

The ERS engine also accounts for vessel geometry and vertical motion: antenna-to-reference-point and transducer offsets, static draft, dynamic draft/squat, loading changes and heave/motion information. Tide and ERS remain independent solutions until cross-validation, where bias, RMSE, maximum absolute difference and spatial/temporal patterns can be reported.

14. MBES Survey-Time and Track Coverage Engine

The application can read survey acquisition information for timing and position without needing to alter the sonar data. The goal is to prove that the water-level/vertical correction actually covers every required survey epoch and, where spatially varying corrections are used, every required vessel location.

This is a crucial distinction between a tide file that merely parses and a correction that is fit for the survey. Coverage checks can identify missing intervals, unapproved extrapolation, station-zone gaps, model NoData, datum mismatches and other conditions that must be resolved before release.

15. Quality Control, Uncertainty and Fail-Closed Safety

QC is distributed through the pipeline rather than appended at the end. Integrity checks cover checksums, record counts, parser errors, duplicate conflicts and invalid numeric values. Temporal QC covers monotonic time, sampling changes, gaps, overlaps, timezone/DST interpretation and leap-second/GPS issues. Signal QC can flag spikes, flat-line blocks, unrealistic rates and datum jumps. Geodetic QC covers vertical datum, CRS, reference frame, epoch, tide system, model area and transformation uncertainty. Spatial QC checks station positions, survey distance, zone coverage, NoData and extrapolation distance.

Uncertainty is propagated through transformations. Independent components may be combined using root-sum-square logic, while correlated components are handled through covariance/Jacobian propagation. The project can retain one-sigma uncertainty internally while reporting the required confidence quantity and comparing it with project or IHO S-44-style limits.

Suspect observations are flagged rather than silently deleted. Hard failures produce explicit reason codes. Release gates are fail-closed: a missing required signature, unresolved datum, invalid transformation, incomplete coverage or failed round-trip test keeps the output out of the final state.

16. Activity, Evidence and Operational Traceability

The activity/results panel gives the operator a concise view of what actually happened during retrieval, processing and export. Provider-specific operations can be filtered, searched and exported, while detailed diagnostics remain available when a physical acceptance or regression issue needs investigation.

The example below shows multiple SMHI retrievals completing through processing and multi-export. The important point is that the displayed PASS is attached to the complete operation—not just a successful download.

17. IHO S-100 Foundation

S-100 is the IHO Universal Hydrographic Data Model. The IHO Registry describes S-100 as the framework of related parts used to develop and maintain hydrographic data products and registers, aligned with ISO 19100 geospatial standards. The current S-100 version associated with S-104 Edition 2.0.0 is S-100 Edition 5.2.0.

UniversalHydroTide does not treat “S-100 support” as a single file-extension checkbox. The implementation separates product-schema rules, HDF5 encoding, exchange-set packaging, catalogue metadata, validation, signatures and production acceptance so that each layer can fail independently and visibly.

18. S-104 Water Level Information for Surface Navigation — Detailed Implementation

S-104 is the IHO product specification for Water Level Information for Surface Navigation. IHO identifies Edition 2.0.0 as the first operational edition and associates it with S-100 Edition 5.2.0. S-104 represents water-level information with metadata describing the values, applicable times, locations and structure of the product, and is intended to support adjustment of depth information in an ENC or bathymetric context.

In UniversalHydroTide, S-104 is an additional standards output; it does not replace MBES tide-file adapters. The current production policy intentionally constrains S-104 export to the gridded DCF 2 route. A station time series intended for S-104 is therefore converted to an appropriate governed grid before export rather than being mislabeled as a production S-104 grid.

The S-104 implementation has been developed as a sequence of independent gates: product baseline; Feature Catalogue/HDF5 schema and data-coding governance; native HDF5 writer/reader round-trip; exchange-set governance; CATALOG.XML generation; S-100 Part 15 cryptographic support; and CATALOG.SIGN production/verification. The GUI can discover native S-104/HDF5 artifacts and shows the state of HDF5, S-158, dataset signature, catalogue signature and later exchange checks separately.

S-104 time handling follows the specification requirement to encode timestamps in UTC. Dataset and exchange-set release is conditioned on validation. For ECDIS-oriented exchange sets, required resources must be signed in accordance with S-100 Part 15/17 rules; UniversalHydroTide therefore treats missing or invalid signatures as a release blocker rather than a warning.

• S-104 Edition 2.0.0 product profile integrated as a first-class standards output.
• HDF5 writer and reader with round-trip/schema acceptance tests.
• DCF 2 gridded production policy; station-series data must be transformed to a governed grid before S-104 production export.
• Feature Catalogue and data-coding governance.
• UTC timestamp encoding and product metadata control.
• S-100 exchange-set directory and resource governance.
• CATALOG.XML generation and canonical resource packaging.
• S-100 Part 15 digital-signature support for datasets/catalogues where required.
• CATALOG.SIGN generation/verification path.
• S-158:104 validation integration and persisted validation evidence.
• Fail-closed production acceptance if schema, validation, signature or exchange checks fail.

19. S-158:104 Validation and Digital-Signature Enforcement

IHO S-158 provides the common validation-check framework for S-100 products, and S-158:104 contains the product-specific validation checks for S-104. The current IHO listing shows S-158:104 Edition 1.0.0 as released for implementation and testing. UniversalHydroTide integrates these checks into the production-evidence chain rather than treating them as a manual afterthought.

The screenshot below is intentionally useful because it shows fail-closed behaviour. The HDF5 artifact, S-158 stage and dataset signature can pass while a CATALOG.SIGN trust/signature problem still blocks release. That is exactly the desired behaviour in a hydrographic production system: partial success does not become final acceptance.

20. Target Export Engine for Hydrographic Processing Software

The main operational output of many survey projects remains a tide/water-level file that the selected MBES processing package can ingest. UniversalHydroTide therefore maintains target adapters in addition to S-104. The adapter receives the frozen master solution and serializes only the required representation; it does not recompute the tide.

The architecture distinguishes verified adapters from template/community routes so that support is not overstated. Current project documentation identifies CARIS, QPS/Qimera-QINSy, HYPACK, MB-System and a generic/custom target as verified or primary routes in the mature adapter set, while Teledyne PDS, EIVA NaviSuite, SonarWiz/BeamworX and specialist/legacy ecosystems are handled as template or community routes until target-version fixtures prove the exact file contract.

Every target adapter is subject to syntax/schema checks, re-import/round-trip comparison of timestamps and values, record-count comparison, target-specific fixtures where available, and an export quantisation policy. The extended design explicitly tracks value quantum, time quantum and rounding; half-even rounding is used where that policy is applicable, with tolerance tied to the output quantum so that rounding is not mistaken for physical bias.

21. Output Package and Project Evidence

A successful job is designed to produce more than one tide file. The delivery tree separates the neutral master solution, software-specific targets, standards products, vertical resources, QC evidence and provenance. This makes a project reproducible months or years later without relying on the memory of the original processor.

Typical outputs include a master CSV/XLSX and normalized metadata; one or more target tide files; an optional S-104 HDF5 exchange set; optional geoid/quasigeoid/SEP/hydroid grids and uncertainty grids; QC summary, residual and coverage reports; and a provenance package containing checksums, model versions, transformations, software/adaptor versions and approval evidence.

• 01_Master — normalized water-level master series and metadata.
• 02_Targets — one or more MBES-processing target files.
• 03_Standards — optional S-104 HDF5/exchange-set artifacts plus validation evidence.
• 04_Vertical_Models — optional geoid/quasigeoid/SEP/hydroid and uncertainty surfaces.
• 05_QC — QC summary, residuals, coverage metrics and uncertainty budget.
• 06_Provenance — source hashes, model/provider versions, transformation chain, software version, adapter versions, approvals and diffs.

22. Security, Credentials, Caching and Offline Vessel Operation

Live hydrographic data services have different security models: some are public, some require API keys, some are licensed, and some are contract-gated. UniversalHydroTide is designed so paid credentials and secrets are supplied through controlled user inputs rather than hardcoded into the application. Secret values are not intended to be echoed into normal logs, and Windows credential/security components are used where the credential manager requires protected storage.

Provider transport uses strict TLS verification. The CHS/NOAA production transport work includes managed CA-bundle fallback without disabling peer or hostname verification. Cache metadata records retrieval context, and offline replay permits a vessel or field computer to reuse previously acquired authoritative responses without pretending the replay is a new live fetch.

The system’s offline philosophy is evidence-first: the original API response or file is preserved, fingerprinted and versioned. An offline job can be reproducible because it still knows exactly which source object was processed.

23. Data Lifecycle, Versioning, Review and Approval

The extended production model separates machine QC from human approval. A dataset can be provisional, verified and final. Provider revisions can trigger re-evaluation, and a new master solution can be compared with the preceding version using maximum, mean and RMS differences plus affected survey lines. This avoids a common operational failure mode where a revised gauge series silently changes an already-processed survey.

Final approval is intended to record the reviewer, timestamp and signed provenance evidence. The philosophy is that a green automated test is necessary but does not erase the need for accountable release management on high-value hydrographic projects.

24. Nigeria Capability Route — IOC Lagos and ADMIRALTY Prediction Data

The Nigeria-specific work is being implemented as a controlled regional routing layer rather than as an assumption that one global provider automatically supplies a complete Nigerian hydrographic tide solution. The P3.0-024 build series introduces a Nigeria capability/router that can expose the available routes, gate them by evidence and present them consistently in the GUI.

For latest/near-real-time water level, the intended public/global route uses IOC/SLSMF where an appropriate Lagos station is available and the credential, station metadata and operator/datum evidence are acceptable. Because SLSMF may provide relative water level without an authoritative chart-datum transformation, the software does not automatically promote a relative series into a hydrographic reduction.

For authoritative prediction, the Nigeria route includes a UKHO/ADMIRALTY prediction-file path. This is deliberately treated as a licensed/file-based capability rather than something assumed to be free or automatically included in the API. The real Nigeria-specific ADMIRALTY product is intended to be purchased/obtained near the end of the P3.0-024 acceptance sequence, when the software route is ready for physical file validation, rather than paying before the software implementation can use it.

At the date of this post, Nigeria routing and physical acceptance are active development/qualification work. The article therefore presents this capability as an implemented routing framework with continuing live/file acceptance, not as a completed national hydrographic service replacement.

25. Reliability Engineering and Test Strategy

UniversalHydroTide is being developed with regression gates around the physical calculations, adapters, GUI integration and standards outputs. Dedicated tests cover datum-transfer logic, harmonic analysis and astronomy, production prediction, residuals, tidal datums, pressure-gauge processing, spatial zoning, grid interpolation, multi-surface colocation, S-104 schema/HDF5, exchange-set governance and signatures.

A key engineering principle is that a test should prove the production path rather than a GUI-only shortcut. The GUI acceptance work explicitly requires production calculations shown on screen to be routed to the native backend or an already-qualified native controller. Provider checks similarly avoid synthetic PASS states: if the real fetch, parser, datum handling or export fails, the acceptance result is allowed to fail so the defect can be fixed.

26. What the Software Can Do in a Real Project

Consider a multibeam survey where the vessel has a GNSS trajectory, a local tide gauge, access to a national water-level API, a regional geoid model and an MBES processing requirement for CARIS plus a client request for standards-based S-104 deliverables. UniversalHydroTide can preserve and fingerprint all sources, normalize them to one time/vertical model, transfer the gauge series to the project datum, process or predict tide where justified, build or apply the required SEP, compare conventional tide with ERS, verify that the final correction covers the complete MBES track, propagate uncertainty, freeze the validated master series, export the CARIS tide file, and separately generate the S-104 gridded product and its conformance/signature evidence.

If one part fails—for example, a separation grid does not cover the project, a provider’s datum is unknown, the survey contains an uncovered interval, or CATALOG.SIGN does not verify—the affected release remains blocked. The operator can still inspect the evidence and repair the specific problem without losing the rest of the project history.

27. Who Benefits from UniversalHydroTide

The platform is designed for hydrographic surveyors, offshore survey teams, dredging and construction survey groups, ports, cable/pipeline projects, hydrographic offices, marine geomatics organizations and data processors who need repeatable vertical-reference workflows across different providers and software packages.

Its strongest value is in projects where more than one vertical source or output format must be reconciled and where the project needs evidence—not just a tide file. The same architecture is also useful for training because it makes the usually hidden assumptions about time, datum, sign, reference frame and uncertainty visible to the operator.

28. Current Maturity and Responsible Claims

UniversalHydroTide has moved well beyond a file-conversion prototype: it has a native C++/Qt application, project model, provider registry, vertical transformation engine, harmonic and spatial processing components, geoid/height workspace, target exporters, conformance/evidence areas and a multi-stage S-104 implementation. At the same time, not every registered global provider or every proprietary target format is equally mature.

The software intentionally publishes readiness gates. A provider may be native, credentialed, contract-gated, template-only, registry-only, pending or unsupported for a particular time mode. A target adapter may be verified, template or community. That maturity language is part of the product design because it prevents a list of names from being mistaken for proven interoperability.

29. Why S-104 Matters — and Why It Does Not Replace Survey Tide Files

S-104 is important because it provides a standards-based way to distribute water-level information inside the S-100 ecosystem. That improves interoperability between producers and navigation systems and gives water-level products a defined metadata, exchange and validation framework.

For hydrographic survey processing, however, the immediate production need is often still a processing-software tide file or ERS solution. UniversalHydroTide therefore treats S-104 as a parallel standards deliverable, not as a reason to remove CARIS, Qimera/QINSy, HYPACK, MB-System or other target adapters. One validated master water-level solution can serve both purposes without being recalculated independently.

30. Conclusion

UniversalHydroTide is being built as a hydrographic vertical-reference system rather than a generic tide downloader. Its defining idea is that every water-level value must carry enough context to be defensible: source, time basis, units, sign, datum, geodetic frame, epoch, processing history, uncertainty and evidence. The software then uses that context to create one validated physical solution and safely serialize it into the formats a survey project actually needs.

The platform combines live-provider acquisition, local-file ingestion, tide-gauge and pressure processing, harmonic analysis, spatial tide logic, datum transfer, geoid/quasigeoid and SEP/hydroid handling, ERS, MBES coverage checks, uncertainty, multi-target export, audit logging and standards-based S-100/S-104 production. Its S-104 path is not a cosmetic export button: it includes HDF5, DCF2 grid policy, catalogue/exchange governance, S-158:104 validation and S-100 Part 15 signature controls with fail-closed release behavior.

The result is a system intended to make hydrographic water-level and vertical-reference processing more reproducible, more transparent and safer to audit across projects, countries, providers and processing packages.

Standards and Technical References

International Hydrographic Organization (IHO), S-100 — Universal Hydrographic Data Model, Edition 5.2.0. IHO Geospatial Information Registry: https://registry.iho.int/productspec/view.do?category=product_ID&domainS=ALL&idx=207&product_ID=S-100&statusS=5

International Hydrographic Organization (IHO), S-104 — Water Level Information for Surface Navigation, Edition 2.0.0 (first operational edition; S-100 5.2.0). IHO Geospatial Information Registry: https://registry.iho.int/productspec/view.do?category=product_ID&domainS=ALL&idx=209&product_ID=S-104&statusS=5

International Hydrographic Organization (IHO), S-158:104 — Water Level Information for Surface Navigation Validation Checks, Edition 1.0.0. IHO Standards and Specifications: https://iho.int/standards-and-specifications

UniversalHydroTide internal engineering evidence referenced in this post includes the master algorithm/report, CMake regression gates, P3.0-014 functional acceptance checklist, provider qualification notes and P3.0-019/P3.0-024 GUI/physical-acceptance evidence current to September 2026.