feat: Customizable line styles

[daniel-freiermuth]

This PR builts on top of #363

Depending on the background map and the screen and sunlight angle, the default line style can be hard to see. This PR proposes making the line and track styles customizable.

Heading in bright red, COG line thin dotted in black

Track style menu:

Vessel line style menu

[panaaj]

This PR contains a lot of change and is stacked on another PR.
#375 addresses the value propositon and implements a common line-style component and applies it to cog heading lines.
The remainder can be addressed in future as the Tracks API becomes a reality.

[daniel-freiermuth]

Hi @panaaj,

Thanks for taking in some of the changes proposed in this PR. Given the partial integration and that the underlying PR #363 was already merged, I rebased and cleaned up the remaining changes:

• fix: Use lookup table for dash style conversion The current dash-style parsing is fragile for longer dashes.
• fix: Scale line pattern with width Fix that wide lines overbleed their pattern.
• feat: Configurable route and navigation line styles This one is the most important one as the default linestyles are very hard to read with certain underlying charts and certain sunlight conditions.
• feat: Flexible line length units for COG and heading lines What I consider a nice extension of customizable Heading and COG lines.
• feat: Configurable self trail and AIS track line styles Adjustable styles for tracks. Not sure whether you want to take it in now and revert it later or just skip this commit.

Btw, you have editing rights on this PR in case you want to adapt it before merging.

[joelkoz]

Thanks for sticking with this, @daniel-freiermuth — and for rebasing onto #363 once it landed. The dash-style lookup table is a genuinely good catch: the old Array.from(...).map(Number) parse silently breaks on any multi-digit dash value, so that's a real fix, not just a refactor.

A few things before this can move, mostly about scope. Per the project's "one logical change per PR" guideline this is currently doing five distinct things at once, and two of them are bigger than the "line styles" framing suggests:

• The length: number → lineLength: { kind, value } change rewrites a persisted config field and adds migration logic for two legacy formats in cleanConfig(). That's a user-data migration — if it's off, people lose their heading/COG line settings on upgrade. The repo runs vitest (ng test, co-located *.spec.ts), and cleanConfig() in app.config.ts is a clean seam for a regression test that exercises both legacy shapes. I'd want that covered before it merges.
• Moving the self COG-line computation out of skstream.worker.ts into the main thread (drawVesselLines) is an architectural change with perf implications — a lot of boats run Freeboard headless on a Raspberry Pi or Cerbo GX. That deserves its own PR and its own discussion rather than riding along inside a styling change.

So my suggestion would be to split this into focused PRs:

1. the dash lookup-table + width-scaling fixes — these stand alone cleanly and are the most obviously mergeable;
2. configurable route/nav line styles — note this overlaps with Add line-style component  #375, so worth de-duping against what landed there;
3. the flexible length units + the worker→main-thread move, as its own change.

The trail/AIS-track styling is the piece I'd hold until the Tracks API firms up, as @panaaj noted.

Two more things:

• The description still reads "builds on top of fix: Use Rhumb Line instead of Great Circle for drawing cog and heading lines #363" (now merged) and predates the five-commit restructure — could you refresh the text to match the current commits? (And a quick check that the screenshots still reflect the current menus.)
• One question on the route styling: routeFeatureStyles / destinationFeatureStyles are getters that build new OL Style objects on each access, and the route layer's effect() clears + re-parses on every input change. Does that re-parse all routes on every change-detection cycle? Just want to make sure it isn't thrashing on boats with a lot of routes.

Heads-up as well: we've got CodeRabbit running on the repo now, so when you open the split PRs you'll get an automated line-level review on each one too.

Thanks again — this is useful work; I just want it landing in pieces we can each review and revert independently.

[joelkoz]

@daniel-freiermuth Nudge. Is this something you want to pursue merging? Or would you like to close it?