Inconsistent communications.callsignVhf handling

[tkurki]

We are handling callsignVhf inconsistently across three sources

• self settings in server's settings (baseDeltas)
• AIS data from NMEA2000 source
• AIS data from NMEA 0183 source

Settings saved from Admin UI

In basedeltas.json
Prior to 8fdca1a

{
  "path": "",
  "value": {
    "uuid": "urn:mrn:signalk:uuid:14dacab8-de52-437e-b814-b4e8287cc0ff",
    "name": null,
    "communication": {
      "callsignVhf": "AB123"
    }
  }
}

After 8fdca1a

{
  "path": "communication.callsignVhf",
  "value": "AB123"
}

n2k-signalk

129794 AIS Class A static data and 129810 produce deltas like

{
  "path": "communication.callsignVhf",
  "value": "3FJJ4"
}

nmea0183-signalk

VDM and VDO (that uses the same code as VDM) produce deltas like

{
  "path": "",
  "value": {
    "communication": {
      "callsignVhf": "PH510"
    }
  }
},

Discussion

There are two Signal K mechanisms here:

• plain valued properties vs object valued properties
• the empty path special case

Deltas are converted to full Signal K data model whose data is available in the HTTP api. Pathvalues with a non-empty path is converted to a leaf structure that has value, timestamp and source (and possibly multiple values structure). Pathvalue with an empty string as path is converted by fusing the object valued property (value) with the full model - this process does not add the value/time/timestamp structure.

So the situation now is that the latest published SK server has 0183 and settings working the same but N2K differently. The merged PR changes settings to work the same as N2K, leaving NME A0183 the odd one out.

[tkurki]

When it comes to specification the schema says that communications.callsignVhf does not have the value/timestamp/source structure, just the simple property:

      "communication": {
        "callsignVhf": "PH510"
      }

that means that NMEA0183 output and settings up to the latest published version with the empty path results in spec compliant full structure.

[tkurki]

My take out of this is that we should revert the server change and change n2k-signalk to be in line with the spec, settings and nmea0183.

[sbender9]

But wait, am I missing something? This change and n2k-signalk are inline with the spec. Current server and 0183 are not.

[sbender9]

I guess I am reading the spec wrong?

[sbender9]

My humblest apologies to everyone! When I did the server change, I misread the spec and thought the server had it wrong.

I agree, the change should be reverted and n2k-signalk fixed. I can work on that.

This also leaves the original issue be fixed.

[tkurki]

#1832 reverted in #1843.