- From: Steve Block <steveblock@google.com>
- Date: Wed, 1 Sep 2010 11:39:51 +0100
- To: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>
- Cc: "public-geolocation@w3.org" <public-geolocation@w3.org>
Thanks for the comments Claes. > - We propose a boolean 'needsCalibration' property that indicates > that the magnetometer needs calibration. This seems reasonable to me. Unless there any objections, I'll add this to the spec. > - In the current version of the specification the device > orientation data is provided as Euler angles. However, there are other ways > of providing sensor data. I looked at the following interesting > presentation: http://www.youtube.com/user/GoogleTechTalks#p/u/0/C7JQ7Rpwn2k > . At the end of the presentation different ways of exposing sensor data for > developers are described. There are apparently limitations with Euler angles > that occurs when the device is pointing right up, Gimbal lock, > http://en.wikipedia.org/wiki/Gimbal_lock. Do you consider this limitation > acceptable meaning that applications using the Device Orientation Event have > to be constrained taking the Gimbal lock problem into consideration? I'm aware of gymbal lock but I think that it's probably not a problem in most applications. The use of Euler angles still allows us to always express the orientation of the device. The only limitation is that certain device motions will cause extremely rapid changes in some of the angles and I think that for the simple use-cases for which the API is intended, this shouldn't be a problem. > So, have you considered to also provide orientation data as a rotation > matrix? We chose Euler angles rather than a rotation matrix as for simple use-cases (such as determining the device's heading for a compass application, or its tilt for a gaming application), they're easier to work with. If we were to provide a rotation matrix, I think this should be an additional property. Personally, I'd prefer to leave this out, rather than increase the API footprint with properties that can be computed with a JavaScript library. If we see lots of user-feedback for this to be included natively, we could consider adding it in a later version of the spec. > - As the attribute “acceleration” does not include the gravity > component we propose to call it “linearAcceleration”. I'm not sure why the term 'linear' would suggest anything about whether or not gravity is included? Have you seen the latest version of the draft spec, which provides both acceleration and accelerationIncludingGravity? Is this sufficiently clear? > - It would be nice to have more examples on the Device Motion > Event. I've added a couple more. Feel free to suggest any further examples you think would be helpful. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902
Received on Wednesday, 1 September 2010 10:40:20 UTC