Re: [accelerometer] includeGravity parameter turns low-level sensor into high-level fused one.

[Section 6 (Concepts)]( and 
[Section 10 
(Extensibility)]( are the
 key ones here.

The differentiation made between low and high-level sensors in GS 
aren't to do with sensor fusion (though generally, most high-level 
sensors are fused), but about whether the Sensor object describes a 
kind of physical sensor (e.g. a pressure barometer) or the kind of 
data you get out of it (e.g. altitude), _regardless of by which mean 
you actually get that data (in the case of altitude, it could be using
 a pressure barometer or GPS for example). _(As a sidenote, whether 
fusion happens are the SF or HW level is irrelevant for this 

With that distinction in mind, LinearAcceleration would fall in the 
high-level sensor category (there's fusion going on between a 
gyroscope and an accelerometer, you're describing the kind of data you
 get and not the means by which you get it, that data could be 
obtained through different means, albite with much less precision, 
e.g. extrapolating from GPS readings).

So in the accelerometer case, the only thing the `Accelerometer` 
sensor object should provide is raw data accelerometer output 
including gravity. Note that some platforms (e.g. Android) do offer a 
smoothed out output for certain sensors (e.g. gyroscope is calibrated 
for drift), so it might make sense in that case to offer that as an 
option on the `Gyroscope` object (e.g. `new Gyroscope({ 
correctForDrift: true });`), again defaulting to raw output.

Note that I'm more than happy to have this distinction re-discussed 
and modified, but, again, this needs to be done at the GS level, so 
all extension spec have the same understanding and apply this 

GitHub Notification of comment by tobie
Please view or discuss this issue at 
using your GitHub account

Received on Friday, 2 September 2016 11:46:52 UTC