References to units should be in ASCII only

[keesverruijt]

When a unit has a Unicode string (for instance \u00b0 for degrees) label this ends up in various places in the model, which might not be readable in all editors.

The 'units' description in definitions.json should contain a map "label": { "display": "\uxxxx" .... }

[jboynes]

The display text for these units in some places uses characters from the CJK compatibility block that are discouraged (e.g. "\u33ad" for "rad") even though they do semantically represent the unit. This is not consistent though with some using canonical forms even though there are characters to represent them (e.g. "\u33ad/s" rather than "\u33ae" for "rad/s" or "Hz" rather than "\u3390" for frequency).

How about moving the display information from definitions.json to i18n/en.json where the display form and description could be localized. This could then include localization of units as well, for example displaying speed in knots. However, localization would also add the problem where different units are used depending on application (for example, boat speed in knots vs. line speed in ft/min, or fuel consumption in gph vs. air flow in cu. ft./min).

This could be addressed by using a semantic reference in the metadata rather than a raw unit. For example, storing unitType in meta rather than units, something like:

"vessel": {
  "speedThroughWater": {
    "value": 1.0,
    "meta" : {
      "unitType": "speed.boat"
    }
}

In en_gb.json:

"unitTypes" : {
  "speed.boat" : {
    "unit": "m/s",
    "display": "m/s",
    "ratio": 1.0
  }
}

In en_us.json:

"unitTypes" : {
  "speed.boat" : {
    "unit": "m/s",
    "display": "kts",
    "ratio": 1.94384
  }
}

[tkurki]

The specification json schema files are the master for unit information. Did you notice https://github.com/SignalK/specification/blob/master/keyswithmetadata.json ? That is generated from json schema.

I'm not 100% convinced that the extra indirection layer for specifying the display units is worthwhile. In the end the display units are up to the Signal K consuming application.

[keesverruijt]

If we do start catering for localization we should also cater for locales that use more than one presentation for a particular value. Nautical distance is expressed differently in some locales depending on the distance.

For example
1 NM = 1 NM (UK) = 1 NM (NL)
but
0.1 NM = 1 Cb (UK) = 182 m (NL)

I guess this is why my Navico chartplotter has a "small distances" and "large distances" unit selection mechanism.

The next problem is that some people like a particular language but not a particular locale. Myself, I'm particular to and I prefer an english language UI but with local units.

[jboynes]

That is the kind of use-case I was envisioning by this change. How a quantity is presented can depend on what is being measured, the locale of the user (both language and location i.e. en_GB differently to en_US or en_DE), and ultimately user preference.

Quantity would be a more suitable name that unitType to fit with SI terminology. My thought would be to have a self-describing naming scheme for them so that they would always roll up to some well known value. For example:

length -> "m"
length.distance -> "NM"
length.measurement.vessel -> "ft"
length.depth -> "fathom"

volume -> "m3"
volume.liquid -> "gal"
volume.liquid.beer -> "pint"
volume.liquid.lake -> "acre ft"

The rules for formatting a value can be specified for each value (supporting @canboat's case); this is similar to how ICU encodes rules for its MeasureUnit in its underlying model.

@tkurki Moving this to i18n separates this from the data model and makes it a presentation concern. Basing this off the key values (like keyswithmetadata does) covers keys defined by the schema but provides no information for open content i.e. values present in a model but not explicitly defined by the schema.

As an example, navigation.position currently does not define depth. If a submersible reported that as open content with the key navigation.position.depth the presentation layer would not have any information on how to display it other than the base unit. As such environment.depth.belowSurface would be localized to fathom but the open value would be left as metre - with the model above, both would consistently localized to fathom

[tkurki]

Sounds like something that would come useful, but a closed SI unit issue is the wrong place to have this discussion. Would you care to outline your solution in a separate issue? And I encourage you to come up with content for an actual solution & submit a pull request.

In Signal K context it all starts with the schema keys - your UI gets data for a key, say navigation.position and then the UI needs to know what unit the data should be converted to for display for this user and what (abbreviated or full) unit name to show. Or allow the user to tweak the different possible units for a key.

The open content part I don't get - how and why would stuff not in the schema be mapped in Signal K localization files?