EncDotNet.S100.Core 0.16.0

EncDotNet.S100.Core

Core abstractions and pipeline framework for working with S-100 based nautical chart data.

Overview

This library provides the foundational types used across the EncDotNet.S100 libraries, including:

• Asset sources — IAssetSource abstraction for reading files from directories (FileSystemAssetSource) or ZIP archives (ZipAssetSource).
• HDF5 abstractions — IHdf5File and IHdf5Group interfaces for reading HDF5 data without binding to a specific HDF5 library.
• HDF5 reader exceptions — S100DatasetSchemaException (a required attribute/group is missing or malformed) and S100DatasetNotSupportedException (the file uses an optional spec feature the reader doesn't yet implement). Both carry product, file, group path, spec reference, and a .WithFile(...) helper used by processor layers to attach the source file name. Hdf5RequiredAttributeExtensions provides ReadRequiredDoubleAttribute / ReadRequiredInt64Attribute / ReadRequiredStringAttribute that translate backend "missing attribute" failures into these typed exceptions.
• Lua scripting abstractions — ILuaEngine and ILuaContext interfaces for running sandboxed Lua portrayal scripts, plus the S100LuaHost host API.
• Coverage pipeline — ICoverageSource, ICoverageRenderer<T>, CoveragePipeline, and supporting types (GridGeoreferencer, CoverageColorScheme, StyledCoverageLayer) for rendering gridded data. ICoveragePortrayalCatalogue.ResolveColorScheme returns CoverageColorScheme?; catalogues that only emit symbology (e.g. S-111's arrow-only portrayal) return null and the coverage renderers throw if invoked on a layer with a null scheme.
• Vector pipeline — IVectorSource, IVectorPortrayalCatalogue, VectorPipeline, and the DrawingInstruction hierarchy (AreaInstruction, LineInstruction, PointInstruction, TextInstruction) modelled directly on the S-100 Part 9 display list. Portrayal-rule execution is pluggable behind IVectorRuleExecutor (the engine-agnostic rule stage the pipeline runs and merges). Two engine siblings implement it: Pipelines.Vector.Xslt.XsltRuleExecutor (S-100 Part 9 §9.4 — owns FeatureXML acquisition, rule selection, XSLT transformation, and display-list assembly) and Pipelines.Vector.Lua.LuaRuleExecutor (S-100 Part 9A). VectorPipeline itself is now reduced to running the built-in XSLT executor, appending the optional injected Lua executor's output, then applying the shared viewing-group / display-plane filter and priority sort; it no longer contains any XSLT-specific code. The Lua executor is a single product-agnostic executor driven entirely by injected seams (ILuaDataProvider / ILuaDataProviderFactory host bridge, LuaContextParameterBinding mariner→parameter mapping, IFeatureAnchorProvider, and IDrawingInstructionTransform), so S-101 and S-131 share one executor and supply only their product-specific seams. DrawingInstructionParser also lives here.
• Validation framework (EncDotNet.S100.Validation) — spec-agnostic types for expressing normative-clause checks against the typed data models: IValidationRule<TModel>, ValidationRuleSet<TModel> (lint-pass runner that collects all findings and traps per-rule exceptions), ValidationFinding (rule id, severity, message, optional GeoPosition/BoundingBox, related feature id), ValidationSeverity, ValidationContext (carries ReferenceTime and an opaque IServiceProvider? for Tier-3 cross-dataset rules), ValidationReport, and a fluent ValidationRuleBuilder (RuleFor<T>("rule-id").Check(predicate, msg).Build() and .Yield(producer) for multi-finding rules). Per-spec rule packs live in the respective EncDotNet.S100.Datasets.Sxxx/Validation/ folder rather than in separate projects. All fifteen supported products (S-101, S-102, S-104, S-111, S-122, S-124, S-125, S-127, S-128, S-129, S-131, S-201, S-411, S-421, plus S-57 via delegation to S-101) now ship a rule pack. For vector products the rule pack reads from a spec-aligned façade (the S-101 pattern is S101DatasetView / S101FeatureView / S101AttributeView) instead of the raw reader types, keeping the door open for a future typed DataModel projection without breaking rule code. Coverage records expose a GroupPath field (BathymetryCoverage.GroupPath on S-102, WaterLevelCoverage.GroupPath on S-104) that rule packs use as the per-coverage ValidationFinding.RelatedFeatureId.
• Part9DisplayListReader — parses the Part 9 display-list XML produced by XSLT-based portrayal pipelines (S-124 / S-129 / S-421) into the same unified DrawingInstruction hierarchy that S-101's Lua pipeline emits, so a single renderer can consume both.
• Portrayal-instruction caching (Pipelines.Vector.Caching) — a cross-load cache of the post-pipeline DrawingInstruction list so re-opening a previously-portrayed dataset can skip the (for S-101, multi-second MoonSharp Part 9A Lua) portrayal run. IPortrayalInstructionCache.GetOrCompute(key, factory) is implemented by InMemoryPortrayalInstructionCache (bounded LRU, holds list references) and DiskPortrayalInstructionCache (persists each list as a .dlist sidecar via DrawingInstructionSerializer, with atomic temp+move writes, an LRU byte cap, and corruption / FormatVersion-mismatch treated as a miss so a stale or partial file never breaks a render). The caller is responsible for a key that fully captures every portrayal input; S101DatasetProcessor does this with a content hash over the dataset bytes, the feature- and portrayal-catalogue content (including overrides and Lua rules), and the engine assembly versions. Caching at the post-pipeline boundary (rather than raw Lua-emitted strings) means a hit reproduces the exact list a fresh run would, without bypassing any later stage.
• Shared types — IPortrayalCatalogue, ICrsTransform, Viewport, MarinerSettings (S-100 Part 9 §4.2 mariner selections, including the four depth contours and S-101 portrayal toggles such as FourShades, SimplifiedSymbols, RadarOverlay, NationalLanguage), DepthUnit and the DepthFormatting helper for locale-invariant depth conversion / formatting / parsing across metres, feet, fathoms, and combined fathoms-and-feet, BoundingBox, RgbaColor, ColorPalette.
• Dynamic feature sources (EncDotNet.S100.DynamicSources) — graphics-agnostic abstraction for push-driven point/track/area features (own-ship, AIS, route preview, sensor overlays, etc.) that sit alongside static datasets in the rendering surface: IDynamicFeatureSource (snapshot + Changed event), DynamicFeature (geometry vocabulary reused from the static vector pipeline — same GeometryType enum and (Latitude, Longitude) tuple convention), DynamicMotion sidecar for moving point features, DynamicVesselGeometry sidecar for vessel dimensions (length, beam, CCRP/GPS-antenna offsets per IEC 62388 — semantically matches AIS Type 5 dimA/dimB/dimC/dimD), DynamicSourceMetadata (carries DisplayName and RendererKey for DI-keyed renderer resolution in EncDotNet.S100.Renderers.Mapsui), DynamicFeaturesChanged + DynamicSourceChangeKind, and the optional DynamicFeatureTracker<TInbound> helper for adapters with aging semantics (AIS sleep/lost timers, stale-sensor styling). See docs/design/dynamic-feature-source.md for the full design rationale.

Installation

dotnet add package EncDotNet.S100.Core