search

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
92 stars 69 forks source link

Should Values be available in all cases? #426

Closed bkp7 closed 6 years ago

bkp7 commented 6 years ago

Following on from #423, there are a number of cases where there is a "value", but there is no capability to allow "values" in order to cater for multiple sources. This occurs frequently in the schema where a value has not been defined in terms of the global definitions eg numberValue, but where the value is itself more complex and therefore it seems that the values part just hasn't been implemented. Some examples are:

atonType aisShipType environment.mode [day, night, restricted visibility] course.nextPoint course.PreviousPoint (lots more)

Logically if a branch in the tree can have a value, it can be provided from more than one source and so should have the possibility of values too. Is this correct?

A second question this raises after looking at eg. nextPoint: this is defined in the schema as both a branch and a leaf. At present the documentation (from schema parser) picks it up as a leaf:

/vessels/<RegExp>/navigation/courseRhumbline/nextPoint

but according to the schema and the json test files it is also a branch for:

/vessels/<RegExp>/navigation/courseRhumbline/nextPoint/distance
/vessels/<RegExp>/navigation/courseRhumbline/nextPoint/bearingTrue
/vessels/<RegExp>/navigation/courseRhumbline/nextPoint/bearingMagnetic
/vessels/<RegExp>/navigation/courseRhumbline/nextPoint/velocityMadeGood
/vessels/<RegExp>/navigation/courseRhumbline/nextPoint/timeToGo
/vessels/<RegExp>/navigation/courseRhumbline/nextPoint/position

The msg looks like this (valid against vessels schema):

{ "mmsi": "230099999",
  "navigation": {
    "courseGreatCircle": {
      "nextPoint": {
        "value": {
          "type": "Waypoint",
          "href": "/vessels/vessels.urn:mrn:imo:mmsi:230099999/resources/waypoints/urn:mrn:signalk:uuid:4fe4ff38-879a-46ed-9a7d-7caeea475241"
        },
        "timestamp": "2017-01-25T00:23:05.206Z",
        "$source": "a.suitable.path",

        "position": {
          "timestamp": "2017-01-25T00:23:05.230Z",
          "$source": "a.suitable.path",
          "value": {
            "latitude": 49.287333333333336,
            "longitude": -123.1595
}}}}}}

Surprisingly the actual value of nextPoint is not a position, nor does it contain a position. It actually has 2 elements to it being 'type' and 'href'.

Should the above actually look like this??

{ "mmsi": "230099999",
  "navigation": {
    "courseGreatCircle": {
      "nextPoint": {
        "value": {
          "type": "Waypoint",
          "href": "/vessels/vessels.urn:mrn:imo:mmsi:230099999/resources/waypoints/urn:mrn:signalk:uuid:4fe4ff38-879a-46ed-9a7d-7caeea475241",
          "position": {
            "latitude": 49.287333333333336,
            "longitude": -123.1595
          }
        },
        "timestamp": "2017-01-25T00:23:05.206Z",
        "$source": "a.suitable.path",

}}}}

I'm not suggesting we change the schema without good reason, but I would have thought having a branch and leaf combined was not a great idea, and indeed the current parser doesn't cater for it.

bkp7 commented 6 years ago

Looking at other 'complex' values eg. 'draft' (in design.json), they are structured like the second json sample above, and include 'values' as a sibling key to 'value' like all other values. Therefore I suspect that the schema for course and nextPoint (and quite a few others) is not how it ought to be...

bkp7 commented 6 years ago

OK, I can see that having a combined branch and leaf is by design and is called an 'intermediate tree node' #315. Therefore I am closing this issue and opening a separate one to cover just the value/values issue. (#427)