add "at sea" state to differentiate between inshore and offshore state

[leeprevost]

Consider adding a "at sea" state to the plug-in.

Consider this simple js/node module with demo: https://github.com/simonepri/is-sea

This module uses a highly compact (30-40K) series of global territorial boundaries to determine a simple boolean "is-sea" state based on lat/lon position info.

I've also submitted a slight modification to @simonpri 's is-sea module that uses the 12 nm territorial political boundaries as the is-sea boundary test in a PR rather than continental boundaries:

https://github.com/simonepri/is-sea/pull/11 https://github.com/leeprevost/is-sea

I prefer the latter as it filters out the times you pull your nose out of the inlet for a sunset cruise and just captures true "at sea" days.

LP

[bergie]

That’s certainly interesting, and would be cool for stuff like our triplogger plugin. However, I wonder where one would put this in the Signal K data model.

[leeprevost]

Derived data plugin?

[bergie]

Derived data plugin can produce data in certain paths. The auto state plugin currently only writes to navigation.state which has a defined set of values in the signal k spec, and hence no place for an inshore/offshore distinction. But I do like the idea of having this somewhere.

[leeprevost]

yes, I see: https://signalk.org/specification/1.7.0/doc/vesselsBranch.html#vesselsregexpnavigationstate

Could that key point to a dictionary with a few defied keys and allow for some user defined keys?

I guess the other way to do this would be outside of SignalK, possibly as an Influx task or continuous query.

[bergie]

It might be better to introduce a separate key for this. Maybe something like navigation.region with possible values including offshore/inshore? This might be good to discuss on the #specification channel on Signal K Slack before implementing. And then derived data might be a better home for it than this auto state plugin. Or maybe a dedicated plugin altogether?

[bergie]

One reason for doing a dedicated plugin would be that this probably doesn’t need to be calculated for each new GNSS position, but instead maybe something like once per hour (configurable, I’d guess, or maybe adapting to vessel speed?)

[leeprevost]

Agreed. But also something more easily done is post processing like a db continuous query

[bergie]

Out of scope for the auto state plugin. Could easily be a plugin of its own.