W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2010

DeviceOrientation comments

From: Steve Block <steveblock@google.com>
Date: Thu, 22 Jul 2010 14:43:47 +0100
Message-ID: <AANLkTimEZbdEpSQ6qRSE-PCkvA9EPmzxo9kany84FRBH@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: public-geolocation@w3.org
Hi Dean,

Thanks for the comments.

> BTW - I'm commenting on http://dev.w3.org/geo/api/spec-source-orientation.html
> which is currently dated 10 March 2010, although I see comments in the email archives suggesting
> updates since then.
I've updated the date on the spec.

> My main comment/proposal is that Accelerometer Event should include the ability to return
> rotation around the 3 axes.
>From the interface you provide, I think you're suggesting adding rates
of rotation, right? What's the use case you have in mind? Also, why
would you add the rates to the AccelerometerEvent, rather than the
DeviceOrientationEvent, which already reports the values of these
angles? These rates could be determined by numerically differentiating
the DeviceOrientationEvent data, though it's likely that the
implementation could give more accurate results.

> Along these lines, it would be nice if it also included the direction of gravity so that you could easily
> determine the acceleration the user is providing.
I don't think that this is possible. The accelerometer measures the
forces exerted on it, and this includes the force of gravity. There's
no way to independently determine the direction of the gravity force
and hence eliminate it's effects.

> The specification currently says that implementations "must set the values of the unknown angles
> to null", yet the values are defined as doubles.
I've updated the spec to add the fact that these values are nullable

> Lastly, the specification does not provide any way to throttle the rate of incoming events. This
> could be an implementation detail, but I expect nearly every implementation will want to expose
> rate control, so it might be worth specifying it.
In the case of the DeviceOrientationEvent, callbacks are made whenever
the orientation changes, where the definition of a change, and hence
any throttling, is left as an implementation detail. I think this
suffices. In the case of the AccelerometerEvent, the thinking was that
the underlying hardware probably reports the accelerometer data at a
constant, fixed rate. So any attempt to set the rate would lead to the
implementation having to interpolate, which could cause problems for
users of the API which attempt to filter the data. What is the
motivation for setting the rate, other than avoiding superfluous

> I'm not sure why there is a need to report the interval of incoming events if it is a constant, and
> can't really be guaranteed anyway. Without the change above there is no way to control it. Also,
> DOM Events already have a timestamp, so the user can work out the interval themselves.
The idea was that the interval would be taken from the hardware so
would be more precise than the timestamp of the DOM Event, which could
be delayed. The interval is required to allow users of the API to
perform filtering of the data.


Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Registered in England Number: 3977902
Received on Thursday, 22 July 2010 13:44:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:01 UTC