feature: Add base delta config for anchor roller height

[emonty]

When calculating scope for anchoring, distance of the anchor roller (or bridle connection point) above the water line should be added to the depth before applying whatever formula or multiplier the sailor is using. Like beam and draft, it's a fixed quality of the vessel, so isn't going to come from a sensor. Having it as a base delta would allow deriving an "anchoring depth" value from draft and depthBelowSurface.

[tkurki]

Sorry about the delay in answering.

I am a bit hesitant to add "one more hardcoded field" to the admin UI. I just recently added the metadata editing feature, that is "half dynamic": there's a list of metadata keys from the specification and you can add the ones that you need. What is missing from the metadata feature is the ability to add arbitrary keys.

Maybe something like that would be more appropriate here? Even the existing fields might be replaced with this style editor.

[tkurki]

Are you still there?

[emonty]

Hey, yes ... Currently mostly AFK, back next week. Thanks for the pointer, I'll take a look in that direction as soon as I'm back at a computer

[emonty]

I finally got a chance to look at this - and the new metadata editor looks pretty cool. Perhaps if we do a similar thing but to allow adding arbitrary paths? Because I hear you on the hardcoded fields part of it all.

I think there are ultimately two different but related questions here:

• Should there be an agreed upon path for specifying anchor roller height similar to design.draft and friends.
• How should we handle managing static design data.

On the first I'd like to advocate that design.anchorRollerHeight is fundamentally important just like ``design.draftandsensors.gps.fromBow```. It's essential when anchoring to add that height to the depth when calculating scope - and it's also easy to forget to do so. For things like anchor alarm plugins, being able to display a calculated scope is handy - but if they are not adjusting for height such an indicator can give be misleading. Similarly - in the proposed anchoring API - there is a "drop" api call, as well as an API for estimating anchor location. If you know when the anchor was dropped and the motion of the boat, it's trivial to calculate at what point the anchor is likely to have hit the bottom, as long as you know the roller height as well.

But perhaps for that we need a spec proposal instead?

For the second - I really do like the metadata editor approach, and there are some cases I think it will really help. For instance - I have 3 different GPS antennas on my current boat - so I might also make the argument that we should consider sensors.gps.fromBow to be something that should be set on a per-data source basis instead of globally for the boat ... so actually using the metadata editor for that might be a much better approach. I know I can set those values in the Cortex AIS, although I haven't looked to see if it exports those values over NMEA and my boat is currently switched off.

OTOH there is something nice, especially for new users, about being able to simply go add things like height, beam and draft without needing to know which signalk paths those translate to. So maybe it's still ok to let a set of basic vessel qualities have an an easy-button way of configuring them?