- From: Steve Block <steveblock@google.com>
- Date: Wed, 29 Jun 2011 19:02:18 +0100
- To: George Percivall <gpercivall@opengeospatial.org>
- Cc: Dean Jackson <dino@apple.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
> It's recognized that NED was considered and rejected by the editors in lieu of ENU. We looked at the native orientation APIs provided by a variety of mobile device operating systems and concluded that most use an East-North-Up coordinate frame ... - Meego [1] - East-North-Up - Android SensorManager.grtOrientation() [2] - West-North-Down - Other Android APIs [3] - East-North-Up - iPhone [4] - East-North-Up - WindowsMobile [5] - Unclear, but it seems to use a East-North-Up frame We decided therefore that it's best to stick with the East-North-Up frame and to follow existing mobile device APIs, rather than the convention used for vehicles, especially as its not immediately clear how a mobile device relates to a vehicle, as it lacks the concept of a 'forward' direction. (ISSUE-88 [6]). > To avoid mistakes in inertial navigation uses, it would be important to add a comment that "the angles do not match roll-pitch-yaw." Done [7] Thanks, Steve [1] http://apidocs.meego.com/1.2/qtmobility/qaccelerometerreading.html [2] http://developer.android.com/reference/android/hardware/SensorManager.html#getOrientation(float[], float[]) [3] http://developer.android.com/reference/android/hardware/SensorEvent.html [4] http://developer.apple.com/library/ios/#documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/MotionEvents/MotionEvents.html [5] http://msdn.microsoft.com/en-us/library/microsoft.devices.sensors.accelerometer(v=VS.92).aspx [6] http://www.w3.org/2008/geolocation/track/issues/88 [7] http://dev.w3.org/cvsweb/geo/api/spec-source-orientation.html.diff?r1=1.30;r2=1.31;f=h
Received on Wednesday, 29 June 2011 18:02:56 UTC