- From: Rees, Kevron <kevron.m.rees@intel.com>
- Date: Mon, 12 May 2014 08:54:21 -0700
- To: ALDRIC LOYER <aldric.loyer@mpsa.com>
- Cc: Tatsuhiko Hirabayashi <ta-hirabayashi@kddi.com>, Paul Boyes <pb@opencar.com>, Marc Lapierre <mlapierre@qnx.com>, 박종선(Justin Park) <jongseon.park@lge.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
On Mon, May 12, 2014 at 12:43 AM, ALDRIC LOYER <aldric.loyer@mpsa.com> wrote: > Hi Kevron and other contributors to this topic, > Definitely, Apps developers want to use a unique API to get geolocation and, of course, current w3c geolocation API is the good one. And then I agree on the fact that OEMs (or third parties) have to provide the low level framework needed to choose between the native sensor and the added sensor (provided by the vehicle)... > But now the question is the same for the vehicle speed API, do we use the one provided by the standard w3c geolocation API (position.coords.speed) or do we need a specific one ? On principle, I think I would have to say no, we don't need a specific one if vehicle.vehicleSpeed and position.coords.speed are identical. I propose we add something like the following section to the spec: Relationship with other W3C APIs Other W3C APIs can be used to supplement the Vehicle Information API. It is assumed that in a vehicle implementation, these other APIs will provide vehicle attributes. For example, vehicle speed and location information is provided by the Geolocation API. [other examples?]. It is also assumed that these APIs will be implemented using data from the vehicle. -Kevron <snip>
Received on Monday, 12 May 2014 15:54:49 UTC