Fix/chart1 cleanup 2#28
Merged
Merged
Conversation
QualityOfBathymetricData.lua iterates feature.zoneOfConfidence and reads each instance's categoryOfZoneOfConfidenceInData to pick the DQUAL data-quality area fill (the triangle-with-stars / oval-with-U patterns + dashed boundary). But the S-57→S-101 bridge never synthesized that complex attribute: S-57 stores the zone of confidence as a flat CATZOC simple, so the rule saw an empty zoneOfConfidence and emitted nothing — the entire "quality of data" symbology was missing (Chart 1 page 243 / PresLib PDF 252, the major finding for that panel). buildRoot now wraps M_QUAL's CATZOC (and DATSTA/DATEND, if present) in one zoneOfConfidence instance, the same flat-simple→complex pattern already used for clearances, orientation, and date ranges. Re-rendering page 243 now shows all four zones (A1 6-star triangle, B 3-star triangle, D oval-with-asterisks, U oval-with-U) with their dashed quality boundaries, matching the reference plot. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…textures
S-52 PresLib §8.5.4 distinguishes "fill patterns" (widely-spaced discrete
symbols — quality-of-data, aquaculture, fishing) from "textures" (dense
continuous fills — dredged dots, night diamonds). We baked both as a MapLibre
fill-pattern, which tiles one raster cell locked to tile/screen pixels: the
phase is arbitrary relative to an area, so symbols never centre and get clipped
mid-glyph at the boundary ("strange looking pattern fill" the spec warns
against) — visible as half-symbols spilling across the M_QUAL data-quality
boxes.
Now the widely-spaced patterns are placed as discrete WHOLE point symbols on a
geographically-anchored V1/V2 lattice (mm → ground metres at the cell scale):
- a symbol is drawn only where its footprint fits inside the polygon (inset
test), so it never clips or overhangs the boundary (§8.5.1.1);
- an area too small to seat ≥2 symbols collapses to one symbol centred on the
representative point (§8.5.2), matching the reference plot's one-per-box;
- dense textures (DIAMOND1, DRGARE01, NODATA03, …) stay tiled fill-patterns.
The S-57→S-101 bridge annotates the sparse AreaFill (V1/V2/symbol) on the
PatternFill; the baker does the lattice placement (it has the scale + world
coords). Verified on Chart 1 page 243: data-quality zones A1/B/D/u now show one
whole centred symbol with no spillage.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The single centred symbol (and each lattice symbol) for a widely-spaced fill pattern was emitted with CentreOnArea, which routes the client to the "ctr:" sprite variant that centres the content BOUNDING BOX on the point. That variant exists for corner-pivot "…RES" symbols; the DQUAL/MARCUL/FSH… pattern symbols already carry their pivot at their designed centre (the <circle pivotPoint> at 0,0), so the normal pivot-on-point placement centres them exactly while the bbox-centring nudged them off (a downward triangle's bbox centre ≠ its pivot). Drop CentreOnArea so the pattern symbol sits on its pivot — quality-of-data zones now centre cleanly in their boxes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…changes Area fill-pattern TEXTURES bake the physical-size correction into each image's pixelRatio (0.08/FEATURE_SCALE / sizeScale), set once when the image is lazily registered. registerPattern bails on hasImage, so an already-registered pattern is never updated in place — when the mariner calibrates the screen (setPxPitch changes sizeScale, and with it _patternPixelRatio), the point symbols rescale via their data-driven icon-size but the textures keep their stale pixelRatio and render at the wrong (e.g. too-big) physical size relative to everything else. setPxPitch now drops the registered pattern images before rebuilding the style, so the styleimagemissing handler re-registers them at the freshly-computed ratio. The uncalibrated default already matched the reference plot; this fixes the size drift that only appears after calibrating. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…inaccessibility S-52 PresLib §8.5.3 specifies the area representative point is the CENTRE OF GRAVITY (centroid) by default, using another point only when the centroid falls outside the area. We always used the pole of inaccessibility (polylabel). For a wide rectangle the pole is not unique — it slides along the horizontal mid-line — so a centred symbol (e.g. the area TS_PAD tidal-stream diamond) landed visibly off-centre even though its box looked symmetric. areaLabelPoint now returns the ring centroid when it lies inside the even-odd area, falling back to the polylabel search for concave/holed shapes where the centroid is outside. Rectangular and convex areas now centre exactly (the area TS_PAD diamond, and the quality-of-data boxes, sit dead-centre); concave shapes keep the robust pole point. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ne-centred Two contour-labelling fixes: - contourValdco dropped VALDCO=0, so the drying line / chart-datum contour was never baked with a value and could never be labelled "0" (the spec plots show it). It now bakes VALDCO whenever it's explicitly present, including 0 — a missing value is still left unlabelled. Decluttering "0 by the shore" is the mariner's "contour labels" toggle (off by default), not a hard bake-time drop, so the choice is preserved. - The contour-labels layer used symbol-placement "line" with a 300 px spacing, which often places nothing on a short contour segment (the depth-shading demo panels). Switched to "line-center" — one value centred on each contour, as the spec plots show. Harness (preslib-chart1.mjs) now requests contour labels and the depth-shading demo's contour set (shallow 5 / safety 10 / deep 30, drying 0) so the page-243 panels render the intended bands + labels. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… line style S-52 draws a feature whose position is approximate (QUAPOS not surveyed/precise) with a DASHED line — coastline-unsurveyed, rivers, roads, cables, depth contours, etc. The S-101 rules read this from a per-edge spatial-quality association the host stubs out, so it never fired and everything drew solid. QUAPOS is a SPATIAL-level attribute (ATTV on the edge VRID records), not a feature attribute, and was not parsed at all. This adds it end to end: - parser: parse ATTV on spatial records → spatialRecord.Quapos (reusing the ATTF attribute parser; ATTV has the same ATTL+ATVL layout). - geometry: aggregate the drawn edges' QUAPOS to a per-feature Geometry.Quapos — for line features (constructLineStringGeometry) and polygon boundaries (boundaryQuapos, same drawn-edge selection as drawableBoundaryLines). The feature is "low accuracy" when the majority of its drawn edges are. - pkg/s57: expose Geometry.Quapos through the public conversion. - portrayal: switch a low-accuracy feature's solid simple-line strokes to dashed (complex line styles and point symbols keep their catalogue look). Verified on Chart 1 page 241: "coastline surveyed" stays solid while "coastline unsurveyed", river, vegetation, road and cable render dashed, matching the plot. (Per-feature aggregate, not per-edge — a contour with mixed accuracy dashes by its majority; the depth-shading panel's contours carry no QUAPOS so stay solid.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…filter) The date pipeline already bakes date_start/date_end/date_recurring + the CHDATD01 "d" marker, and the client has the mandatory current-date filter (dateDependent) and the CHDATD01 highlight (highlightDateDependent) — but neither was reachable from the UI. Add two toggles under Advanced: - "Hide out-of-date features" (dateDependent, default on) — the S-52 §10.4.1.1 mandatory current-date filter; off shows seasonal/expired features regardless of their validity dates. - "Highlight date-dependent" (highlightDateDependent) — the S-52 §10.6.1.1 CHDATD01 "d" marker on features that carry date conditions. Both keys already trigger a restyle (chart-canvas setMariner), so this is purely the missing UI. The Chart 1 harness now enables both so page 239 renders the date-dependency demo: the "Periodic" feature and the expired "End date 27-08-2014" FlW light both show their magenta "d" markers, matching the plot. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…nning The client already supports a pinned viewing date (mariner.dateView "YYYYMMDD" — _todayParts uses it, and it's in the restyle key set), but there was no way to set it. Add a "date" settings control type (native date input; stores the compact YYYYMMDD the model uses, blank = real today) and a "Viewing date" field under Advanced, beside the date-dependency toggles. Setting it evaluates date-dependent display (the hide-out-of-date filter and the "d" highlight) against that date instead of today — passage planning, and a way to preview seasonal/expired features. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
It's a standard S-52 §10.6.1.1 display highlight — sibling to "Information
callouts" — not a developer/Advanced setting. Move the toggle to the General
tab beside Information callouts. The current-date filter override ("Hide
out-of-date features") and the planning "Viewing date" stay under Advanced.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The swept-area fallback (sweptAreaBuild — the S-101 SweptArea rule is an IHO gap) drew only the dashed boundary and the "swept to N" label, missing the SWPARE51 "⊔" swept-depth bracket the spec plots show with it (Chart 1 page 243 "swept to 4.5"). Place SY(SWPARE51) at the area's representative point, with the label top-anchored just below it so it drops under the bracket instead of overprinting it (the client text layer ignores per-feature pixel offsets, so the vertical position comes from the text anchor). Matches the reference plot: bracket on top, "swept to 4.5" beneath. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The S-101 NavigationalSystemOfMarks rule is an unofficial stub (NullInstruction only), so M_NSYS regions drew nothing (Chart 1 page 248 "IALA A / IALA B / no or other system" was blank). Add a Go-side build, like SWPARE, that strokes each ring with the S-52 NAVARE51 complex line (dashes + EMAREGR1 triangle markers) — the region outline is the same regardless of MARSYS (the system governs the buoy colours inside, not the boundary). M_NSYS is a META_BOUND_CLASS, gated behind the "Metadata boundaries" mariner toggle (off by default), so the Chart 1 harness now enables showMetaBounds to render the demo. The three IALA boxes match the plot; the system-change "A-B-A-B" transition line (a shared edge between different-MARSYS regions) needs spatial adjacency and is not yet drawn. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Remove dead code in portrayal/build.go: applyDangerDepth, isSoundingDigit,
geometryCode, goGeomType, cloneRings+clonePts, maxF32, isUnknownClass — all
unreferenced leftovers from the S-52→S-101 migration (gopls unusedfunc).
- interface{} → any across the three files (gofmt -r).
- bake.go modernize: sort.Slice→slices.Sort, C-style loop→range-over-int,
if/assign→max, and the cross-band suppression switch→tagged switch on r.kind.
No behaviour change; build/vet/test green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Draw the IALA-A↔IALA-B transition with the S-52 MARSYS51 complex line (dashes + the embedded EMMARS01 "A" / EMMARS02 "B" symbols — "boundary between IALA-A and IALA-B systems"), while the rest of an M_NSYS region keeps the generic NAVARE51 triangle boundary. The transition is detected by edge coincidence: an M_NSYS boundary index records, per ~1cm-quantised segment, which IALA systems (MARSYS 1=A / 2=B) carry it; a segment shared by both an A region and a B region is the transition. navSystemBuild splits each ring into runs and strokes transition runs MARSYS51, the rest NAVARE51. Unit-tested with two abutting A/B regions. Note: the Chart 1 page-248 demo cell (the e4.0.0 DRAFT digital files) digitises its IALA-A and IALA-B regions ~11 m apart rather than sharing an edge, so the transition doesn't trigger there — it renders where regions genuinely abut (real ENCs / the final PresLib cell). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The PresLib symbolized M_NSYS lookup (DAI LU00344-347) keys on ORIENT, not on which IALA systems border a segment: a region without a direction of buoyage draws the MARSYS51 "A-B" line (dashes + the embedded A/B symbols), and a region with ORIENT draws the NAVARE51 triangle boundary plus a direction-of-buoyage arrow (DIRBOYA1/B1/01 per MARSYS, rotated to ORIENT). The previous shared-edge index was wrong: the Chart-1 demo models the A-B line as its own no-ORIENT M_NSYS region (the IALA-A/B boxes sit ~11 m apart and share no edge), so MARSYS51 never appeared. Drive it off the feature's own ORIENT instead and the page-248 A-B-A-B line now renders. Drops the nsysIndex/buildNsysIndex/isTransition machinery and the nsysIdx threading through buildFeature/buildFeatureBody. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
DIRBOY01/A1/B1 carry their catalogue pivot at the arrow tail (SVG 0,0, bottom-centre), so anchoring the pivot at the region centre pushed the whole arrow ~30 mm north and out the top of the small demo regions. Set CentreOnArea so the client centres the glyph on the representative point instead (S-52 §8.5.1), keeping the arrow inside its box. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.