W3C home > Mailing lists > Public > public-autowebplatform@w3.org > May 2014

Re: Vehicle Location Information

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Mon, 12 May 2014 08:54:21 -0700
Message-ID: <CAFW5wYYGxhtSkGE+f+7rRXp9BM0yut_89yRE07pD+rp7HerT=Q@mail.gmail.com>
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.


Received on Monday, 12 May 2014 15:54:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:39 UTC