Handle sensors with multiple values

[tobie]

Proposed resolution: the Generic Sensor API needs to support sensors with multiple values. This should be implementable using domain-specific named properties.

[richtr]

DeviceOrientation Events return alpha, beta, gamma values (as well as absolute, webkitCompassHeading, webkitCompassAccuracy values). DeviceMotion Events return a different set of complex values (see: https://w3c.github.io/deviceorientation/spec-source-orientation.html#devicemotion).

Any generic sensors solution needs to allow custom properties to be defined and returned as part of a call to obtain the sensors values.

[tobie]

Agree 100% @richtr. Just need to define what the best way to do that is (in terms of developer friendliness, but also, perf and memory footprint, and compatibility with legacy APIs).

[rwaldron]

+1 @richtr the non-specific value property should be considered a placeholder for the time being.

[borismus]

Android uses float[] values always. It just means different things in different cases. In some cases, like barometric pressure, it's just one value. In other cases, like uncalibrated magnetometer, there are 6 or 7 values that refer to different things.

As far as I'm concerned, the API should be as generic as possible to avoid having to wait on standards bodies every time a new sensor is introduced.

[rwaldron]

Android uses float[] values always. It just means different things in different cases.

As far as I'm concerned, the API should be as generic as possible to avoid having to wait on standards bodies every time a new sensor is introduced.

+1 with all of this, however it would be nice for contextually relevant property names, ie. the actual name of the data, vs. making things up like sensor.currentGeolocationPosition where sensor.longitude and sensor.latitude are more appropriate correct.

[tobie]

Seems there's consensus that supporting multiple values per sensor is a requirement. There are two proposed options for how expose those:

1. array-based (as is done on Android),
2. using named properties.

My preference would go for using named properties as it seems much more Web-y. It's more inline with the best practice of preferring named constants to numerical ones. I also don't believe either solutions would have a measurable impact on the time it would take to spec a new kind of sensor. Whereas named props require… naming, an array-based solution requires specifying the order if you want any kind of interoperability.

Proposed resolution: the Generic Sensor API needs to support sensors with multiple values. This should be implementable using domain-specific named properties.

[rwaldron]

Proposed resolution: the Generic Sensor API needs to support sensors with multiple values. This should be implementable using domain-specific named properties.

+ 1

Here are some examples:

Accelerometer {
  pitch: The pitch angle in degrees. 
  roll: The roll angle in degrees.
  yaw: The yaw angle in degrees. 
  x: Value of x axis in G forces. 
  y: Value of y axis in G forces. 
  z: Value of z axis in G forces. 
  acceleration: The magnitude of the acceleration in G forces. 
  inclination: The incline of the device in degrees. 
  orientation: The orientation of the device (-3, -2, -1, 1, 2, 3). 
}

Coordinates {
  lat: Value of latitude position
  lng: Value of longitude position
}

// ("lat" and "lng" can just as easily be defined in their full name form "latitude" "longitude", 
// but google maps uses "lat" and "lng", so matching the interface seems like a nice user experience

Gyro {
  pitch: The pitch angular velocity in in degrees per second.
  roll: The roll angular velocity in in degrees per second.
  yaw: The yaw angular velocity in in degrees per second.
}

* rate = degrees per second