RE: Vehicle Location Information

Justin,
I think that your justification for acceleration is right. I agree with you.
Concerning vehicle speed, I can also join the position of keeping a specific interface, considering the following use case :
My car is parked in a ferry boat, who’s moving, but I want to play my favorite game on the head unit. For security reason, this game is only available when the vehicle is stopped (Vehicle speed =0). In that case, vehicle speed IS NOT a derivate of the vehicle position, which is, in that case, the speed of the ferry.
Best regards.

--------------------------------------------------------------------------
Aldric LOYER
PSA Peugeot Citroën
Responsable de l'UEI COTI
(Connectivity, Telematic and Infotainment)
Direction de la Recherche et de l'Ingénierie Avancée
Tel : +33 (0) 1 57 59 81 35 (20 81 35)
Portable : +33 6 32 34 55 59

De : 박종선(Justin Park) [mailto:jongseon.park@lge.com]
Envoyé : mercredi 14 mai 2014 13:10
À : 'Paul Boyes'; 'Rees, Kevron'
Cc : ALDRIC LOYER - J433842; 'Tatsuhiko Hirabayashi'; 'Marc Lapierre'; public-autowebplatform@w3.org; 'Philipp Hoschka'; 'Kazuyuki Ashimura'; 'Bernard Gidon'; 'Alan Bird'
Objet : RE: Vehicle Location Information

Dear all,

I’m sorry I couldn’t join the call.
I reviewed the minute and found important points are already addressed.

I also agreed to split DeadReckoning into steeringWheelAngle and wheelTickSensor.

Regarding speed, it’s rather hard to make a decision.
In GENIVI case, although I knew geo-location has it and Webinos decided to remove it from vehicle interface,
I decided to leave it. Because, as Paul mentioned, speed is very important data for vehicle applications. Additionally, I wanted to note explicitly that it is a mandatory item.
In geolocation API, it’s nullable value, and the unit is meters per second. So, it seems not well-fitted to vehicle speed.
Anyhow, if we consider the case of vehicle, it looks unnatural to get speed data from geolocation.

Regarding acceleration, I think we need to leave it.
If we consider BYOD case, acceleration data of mobile device must be distinguished from that of vehicle.
Many mobile games use acceleration data and should still work even in the vehicle.

Best regards,
Justin

From: Paul Boyes [mailto:pb@opencar.com]<mailto:[mailto:pb@opencar.com]>
Sent: Wednesday, May 14, 2014 6:12 AM
To: Rees, Kevron
Cc: ALDRIC LOYER; Tatsuhiko Hirabayashi; Marc Lapierre; 박종선(Justin Park); public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; Philipp Hoschka; Kazuyuki Ashimura; Bernard Gidon; Alan Bird
Subject: Re: Vehicle Location Information

Kevron, Aldric, et al.

Speed, in the context of Geolocation, is part of the Coordinates Interface which in turn is accessible through the Position Interface.  This context is related to yet different than Speed from the vehicle information perspective in that it is related to location.  Speed from a vehicle context does not necessarily have anything to do with location.  It typically means the vehicle is moving under its own power/control at a certain velocity.  I believe the context of acceleration in a vehicle is much the same.  In my opinion they are two related yet different concepts.   I believe we should leave speed and acceleration in the Vehicle Information Spec.

When determining if an attribute/data element should be in the Vehicle Information API or in some other API, I think we need to look at context and concept.  If they are identical, then we should ask,  “In what domain should they fundamentally reside?”  If the context and concept are different, they more than likely they should reside in both domains.

What do you think?

Paul J. Boyes
--------------------------------
Mobile:   206-276-9675
Skype:  pauljboyes



On May 13, 2014, at 11:11 AM, Rees, Kevron <kevron.m.rees@intel.com<mailto:kevron.m.rees@intel.com>> wrote:

I'm okay with Aldric's proposal.  Adding to his justification is
Paul's from the meeting: the vehicle information spec is extensible.
OEMs can implement the API with geolocation and vehicle speed, etc.

Aldric, do you want to do a merge request with your proposed changes?

-Kevron

On Tue, May 13, 2014 at 9:22 AM, ALDRIC LOYER <aldric.loyer@mpsa.com<mailto:aldric.loyer@mpsa.com>> wrote:
Hello,

You’ll find attached a formalization of my proposal to be discussed.

Best regards



--------------------------------------------------------------------------

Aldric LOYER

PSA Peugeot Citroën

Responsable de l'UEI COTI

(Connectivity, Telematic and Infotainment)

Direction de la Recherche et de l'Ingénierie Avancée

Tel : +33 (0) 1 57 59 81 35 (20 81 35)

Portable : +33 6 32 34 55 59



De : Paul Boyes [mailto:pb@opencar.com]
Envoyé : lundi 12 mai 2014 22:22
À : ALDRIC LOYER - J433842; Rees, Kevron; Tatsuhiko Hirabayashi; Marc
Lapierre; 박종선(Justin Park); public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>; Philipp Hoschka;
Kazuyuki Ashimura; Bernard Gidon; Alan Bird


Objet : Re: Vehicle Location Information



For our discussion tomorrow and at the face to face, regarding new APIs, for
those suggesting a new API, please come prepared with very specific
arguments and examples.  Ideally you will ultimately have the following:

paper laying out use cases and one or more of the following:

recommended changes to existing W3C spec and why
recommended changes to the vehicle information spec and why
recommended new api for our group and why it is needed given other W3C APIs

Adam, Philipp, Kaz, Bernard, and Alan, et al.



Please let us know if I have missed anything and any other details those
suggesting new APIs need to consider.  Your thoughts would be much
appreciated.





Paul J. Boyes

--------------------------------

Mobile:   206-276-9675
Skype:  pauljboyes







On May 12, 2014, at 9:27 AM, ALDRIC LOYER <aldric.loyer@mpsa.com<mailto:aldric.loyer@mpsa.com>> wrote:



I guess vehicle.acceleration (4.9.18) is in the same case,  there is very
probably already this API somewhere in W3C APIs.
Concerning vehicle.temperature, as we consider inside vehicle and outside
vehicle, I guess we can keep them as fully vehicle oriented.
All other vehicle interface are, for me, fully vehicle oriented.
To be discussed tomorrow or next week.
Best regards

--------------------------------------------------------------------------
Aldric LOYER
PSA Peugeot Citroën
Responsable de l'UEI COTI
(Connectivity, Telematic and Infotainment)
Direction de la Recherche et de l'Ingénierie Avancée
Tel : +33 (0) 1 57 59 81 35 (20 81 35)
Portable : +33 6 32 34 55 59


-----Message d'origine-----
De : Rees, Kevron [mailto:kevron.m.rees@intel.com]
Envoyé : lundi 12 mai 2014 17:54
À : ALDRIC LOYER - J433842
Cc : Tatsuhiko Hirabayashi; Paul Boyes; Marc Lapierre; 박종선(Justin Park);
public-autowebplatform@w3.org<mailto:public-autowebplatform@w3.org>
Objet : Re: Vehicle Location Information

On Mon, May 12, 2014 at 12:43 AM, ALDRIC LOYER <aldric.loyer@mpsa.com<mailto: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>