EncDotNet.S100.Datasets.S201
0.16.0
dotnet add package EncDotNet.S100.Datasets.S201 --version 0.16.0
NuGet\Install-Package EncDotNet.S100.Datasets.S201 -Version 0.16.0
<PackageReference Include="EncDotNet.S100.Datasets.S201" Version="0.16.0" />
<PackageVersion Include="EncDotNet.S100.Datasets.S201" Version="0.16.0" />
<PackageReference Include="EncDotNet.S100.Datasets.S201" />
paket add EncDotNet.S100.Datasets.S201 --version 0.16.0
#r "nuget: EncDotNet.S100.Datasets.S201, 0.16.0"
#:package EncDotNet.S100.Datasets.S201@0.16.0
#addin nuget:?package=EncDotNet.S100.Datasets.S201&version=0.16.0
#tool nuget:?package=EncDotNet.S100.Datasets.S201&version=0.16.0
EncDotNet.S100.Datasets.S201
Library for reading and portraying IHO/IALA S-201 (Aids to Navigation Information) datasets.
What S-201 is — and how it differs from S-125
S-201 is the IALA-led S-100 product specification for authority-to-authority Aids to Navigation data exchange. It carries the rich, authoritative AtoN model used by IALA member authorities — operational and technical attributes, equipment lifecycle, AIS-AtoN routing, and so on. It is not intended for ECDIS display.
EncDotNet.S100.Datasets.S125
covers overlapping physical objects (lights, buoys, beacons, AIS aids)
but is the leaner ECDIS-facing AtoN feature set defined by IHO. The two
specs share a problem domain but are separate standards with
separate Feature Catalogues, separate XSDs, separate Portrayal
Catalogues, and separate intended audiences.
| Use case | Spec |
|---|---|
| ECDIS display of AtoN | S-125 |
| Authority-to-authority AtoN exchange (operational/technical detail) | S-201 |
This library treats S-125 and S-201 as fully independent products. If both an S-125 and an S-201 dataset cover the same area the viewer renders them as independent layers; no merging or deduplication is attempted.
Features
- Parse S-201 GML datasets (S-100 Part 10b encoding using the S-100 GML 5.0 profile; legacy 1.0 namespaces are also tolerated)
- Namespace-driven feature recognition — no hard-coded allow-list of the 62 concrete S-201 feature types
- Capture xlink cross-references and split them into:
- information references (target is an information type — e.g.
AtoNStatus→AtonStatusInformation,Positioning→PositioningInformation) - feature references (target is another feature — e.g.
theParentFeature/theSubordinateFeaturefrom theStructure/Equipmentaggregation,peerfromAggregations/Associations)
- information references (target is an information type — e.g.
- Project to the S-100 Part 9 FeatureXML neutral form
(
Dataset/Features/*plusDataset/InformationTypes/*) consumed by the S-201 portrayal catalogue - XSLT-based portrayal via the bundled S-201 Portrayal Catalogue
(top-level template
main_PaperChart.xsl)
Overview
Key types:
S201Dataset— root model containing parsed features, information types, and dataset identification. ProvidesResolveReferencedFeatures/ResolveReferencedInformationTypeshelpers for walking xlinks by role name.S201Feature— a geographic feature with type code, geometry, simple/complex attributes, information references, and feature references. ImplementsIGmlFeature.S201InformationType— an information type instance (e.g.AtonStatusInformation,PositioningInformation,AtoNFixingMethod,SpatialQuality). ImplementsIGmlInformationType.S201InformationReference— a feature → information-type binding captured from anxlink:hrefattribute.S201FeatureReference— a feature → feature binding (e.g. equipment ↔ host structure) captured from anxlink:hrefattribute.S201ComplexAttribute— a complex attribute group with sub-attribute values. ImplementsIGmlComplexAttribute.S201FeatureXmlSource—IFeatureXmlSourceadapter that projects anS201Datasetinto the synthesisedDataset/Features/*shape that the S-201 XSLT rules match against.S201PortrayalCatalogue—IVectorPortrayalCatalogueimplementation that loads XSLT rules, symbols, line styles, area fills, and color palettes from the bundled catalogue.
Strongly-typed data model
S201Dataset is a faithful but loosely-typed feature bag — attributes
arrive as ImmutableDictionary<string, string>, xlinks are unresolved
strings, and equipment ↔ host-structure subordination must be walked
by hand. The EncDotNet.S100.Datasets.S201.DataModel namespace
adds a strongly-typed projection on top of that bag:
S201AtonInventory— root entity. Exposes typed views (Structures,Equipment,ElectronicAtoNs), plus the resolvedAggregations,Associations,StatusInformation,PositioningInformation,FixingMethods, andSpatialQualitiescollections.S201AtonObject(abstract base) — the common AtoN attributes shared by every concrete leaf: identifier, lifecycle dates (InstallationDate,FixedDateRange,PeriodicDateRange), inspection metadata, source provenance, AtoN status timeline, and geometry as an enum (S201GeometryKind) plus a flatImmutableArray<GeoPosition>.S201StructureObject— concrete subclass for beacons, buoys, landmarks, lighthouses, light vessels, offshore platforms, etc. AddsAtoNNumber,AidAvailabilityCategory,Condition,ContactAddress, the resolvedMountedEquipment, and typedPositioningInformation/FixingMethodsbindings.S201Equipment— concrete subclass for daymarks, fog signals, radar reflectors, racons, power sources, etc. Exposes the back-resolvedHostStructure(the headline subordination value-add).S201Light—Equipmentsubclass collapsing the four FC light leaves (LightSectored,LightAllAround,LightAirObstruction,LightFogDetector) into a single class discriminated byLightKind. AddsHeight,Statuscodes,VerticalDatum,VerticalLength,EffectiveIntensity,PeakIntensity.S201ElectronicAtoN— collapses the three AIS-AtoN FC leaves (VirtualAISAidToNavigation,PhysicalAISAidToNavigation,SyntheticAISAidToNavigation) into one class discriminated byAisAtonKind. CarriesMmsiCode, AISStatus, and (for Physical / Synthetic variants) the resolvedHostStructure.S201GenericAtonObject— fallback for AtoN features the typed model has no dedicated subclass for (e.g.NavigationLine,DataCoverage,DangerousFeature). Carries the commonS201AtonObjectattributes plus geometry and round-trips everything else throughExtraAttributes.
The projection is read-only and never throws except when the
source dataset has neither features nor information types. Every
other failure — unresolved xlinks, attribute parse errors,
unexpected target types — surfaces as a
ProjectionDiagnostic entry on the out parameter.
How this differs from the S-125 typed model
Both S-201 and S-125 carry AtoN data, but they are independent specifications with different audiences (operational vs ECDIS display). The S-201 typed model exposes:
- Equipment ↔ host-structure subordination as a typed
bidirectional reference (
Equipment.HostStructure,Structure.MountedEquipment). - AtoN lifecycle (
InstallationDate,FixedDateRange,PeriodicDateRange) on every AtoN. - AtoN status timeline via the
AtoNStatusinfo-binding, including theChangeTypescodelist. - Positioning / fixing-method bindings on structures.
- Remote monitoring system metadata on equipment.
The two typed models share only the abstractions in
EncDotNet.S100.Core.DataModel (GeoPosition,
ProjectionDiagnostic, ProjectionContext, XlinkResolver,
AttributeParser, ExtraAttributes). They do not share any
spec-level types. If your application consumes both, project each
dataset to its own typed model and reconcile at the call site.
Quick start (typed model)
using EncDotNet.S100.Datasets.S201;
using EncDotNet.S100.Datasets.S201.DataModel;
var dataset = S201Dataset.Open("aton.gml");
var inventory = S201AtonInventory.From(dataset, out var diagnostics);
// Walk the inventory by host structure.
foreach (var structure in inventory.Structures)
{
Console.WriteLine($"{structure.FeatureClass} {structure.AtoNNumber}");
foreach (var equipment in structure.MountedEquipment)
{
var kind = equipment is S201Light light
? $"Light/{light.Kind}"
: equipment.FeatureClass;
Console.WriteLine($" → {kind} {equipment.Id}");
}
}
// Filter AIS AtoNs by kind.
foreach (var ais in inventory.ElectronicAtoNs.Where(a => a.Kind == AisAtonKind.Virtual))
Console.WriteLine($"Virtual AIS {ais.Id} MMSI={ais.MmsiCode}");
// Diagnostics are non-fatal.
foreach (var d in diagnostics)
Console.Error.WriteLine($"{d.Severity} {d.Code}: {d.Message}");
Notes
- S-201 Edition 2.0.0 application schema namespace is
http://www.iho.int/S-201/gml/cs0/1.0. Note the legacy-style hyphen and/gml/cs0/1.0suffix; this is intentional and distinct from the cleanerS125/1.0form. - Geometry uses the S-100 GML 5.0 profile namespace
http://www.iho.int/s100gml/5.0. The reader is also tolerant of the older S-100 GML 1.0 profile namespaces still seen in some pre-publication encoders. - Coordinate ordering in
<gml:pos>/<gml:posList>follows the S-100 Part 10b §6.2 convention of lat lon forEPSG:4326. - The bundled portrayal catalogue is taken from the IALA-IGO upstream
repository at commit
7ddfe8145812141fb8ca413107254f42febd893e; seeEncDotNet.S100.Specifications/content/S201/README.mdfor full provenance and the upstream → bundled rename mapping. The catalogue ships a single Day-only color profile. - Renderers must tolerate geometry-less features — abstract
supertypes such as
AidsToNavigation,StructureObject, andEquipment, plus aggregation containers likeAtonAggregationandAtonAssociation, may carry no geometry. - Time validity (
fixedDateRange,periodicDateRange) is interpreted as UTC; do not coerce to local time at the source.
License
The bundled S-201 specification assets in EncDotNet.S100.Specifications
are © IALA and used in accordance with their open-publication terms;
see https://github.com/IALA-IGO/S-201_AtoN-Information.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 was computed. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- EncDotNet.S100.Core (>= 0.16.0)
- EncDotNet.S100.Portrayals (>= 0.16.0)
- EncDotNet.S100.Specifications (>= 0.16.0)
-
net8.0
- EncDotNet.S100.Core (>= 0.16.0)
- EncDotNet.S100.Portrayals (>= 0.16.0)
- EncDotNet.S100.Specifications (>= 0.16.0)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on EncDotNet.S100.Datasets.S201:
| Package | Downloads |
|---|---|
|
EncDotNet.S100.Datasets.Pipelines
Per-spec IDatasetProcessor implementations, the DatasetPipelineFactory (file -> processor detection), the headless image-render capability, the S-98 interoperability authority, and the validation runner for IHO S-100 product datasets. Consumed by the EncDotNet.S100 convenience package, the viewer, and the s100 CLI. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 0.16.0 | 87 | 6/8/2026 |