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

Re: Vehicle Location Information

From: Rees, Kevron <kevron.m.rees@intel.com>
Date: Wed, 7 May 2014 10:34:01 -0700
Message-ID: <CAFW5wYazzgdjVL-poKYMxTYuE-DvPN3LCsd73YB+1rdeag4+8A@mail.gmail.com>
To: Tatsuhiko Hirabayashi <ta-hirabayashi@kddi.com>
Cc: Paul Boyes <pb@opencar.com>, "public-autowebplatform@w3.org" <public-autowebplatform@w3.org>
On Wed, May 7, 2014 at 2:45 AM, Tatsuhiko Hirabayashi
<ta-hirabayashi@kddi.com> wrote:
> Hi, Kevron-san
>
> If the high-grade IVI system you mentioned is available, high accurate data will
> be provided without any problem by geo-location API.
>
> However, the fact is that there are some type of IVI system using smartphone.
>
> The following types will have difficulty to get high accurate positioning data
> by using geo-location API even if accurate positioning data is available
> in vehicle or built-in navigation device;
>
> Case-1
>    Smartphone (BYOD) is operating as a head unit, and having full functionality
>    and connectivity with vehicle;   App run on the phone.
> Case-2
>    Smartphone (BYOD) is operating in conjunction with a head unit in vehicle;
>    Apps run on the phone.
>
> In either case, geo-location API generated by these apps will be terminated within
> the phone, and it is so difficult for us to access accurate data.
>
> Therefore, I thought that vehicle location API would be needed as a distinct API
> other than geo-location API.
>

I think the right thing to do in this case is to recommend that phone
OEMs that wish for their phone's to be "vehicle-aware", also make
their geolocation API implementation vehicle-aware.

Even if we duplicate the location API inside the vehicle info spec,
there's no guarantee that the phone implementation will use vehicle
data.

Maybe the solution is to add some "guidance" section to the spec that
details how we believe location data should be handled?

Regards,
Kevron

>
> Thanks
>
> T.Hirabayashi/KDDI
>
> -----Original Message-----
> From: Rees, Kevron [mailto:kevron.m.rees@intel.com]
> Sent: Wednesday, May 07, 2014 8:24 AM
> To: ta-hirabayashi@kddi-ri.jp
> Cc: Paul Boyes; public-autowebplatform@w3.org
> Subject: Re: Vehicle Location Information
>
> On Tue, May 6, 2014 at 3:44 PM,  <ta-hirabayashi@kddi-ri.jp> wrote:
>> Thanks Kevron-san.  See my comments in line below:
>>
>> 1 - Is the geolocation API good enough for vehicles?  If not, we need
>> to work with that group to fix it.
>>
>> #1 As mentioned, the geolocation API is not good enough for vehicles.
>> We need some correction of positioning data acquired by the
>> geolocation API for vehicle in Japan.
>>
>
> Is the correction done in the implementation or the API?  What
> additional APIs do you need other than what the geolocation API
> provides?  The Location API we had in our spec had even less
> information than what is available today in the geolocation spec.
>
> I guess what I'm trying to clarify is that the geolocation API
> implementation in a vehicle need not be the same as a mobile phone
> implementation.  While Position.coords.latitude
> (http://dev.w3.org/geo/api/spec-source.html#position) might not be
> very accurate in a mobile phone, the implementation of the same API
> can be very accurate in a vehicle (due to different antenna
> positioning, additional data from the vehicle, dead reckoning, etc.).
> But the API is the same in both.
>
> If there are vehicle-specific APIs that need to be added for location
> other than what's already in the geolocation spec, I'd like to know
> what those are.  Otherwise, we should assume that the geolocation api
> implemented in a vehicle will have the most accurate fix possible
> -which means it will be a different implementation than a simple
> mobile implementation.
>
> -Kevron
>
>> We understand that vehicle location informantion API is needed to get
>> the
>> result after some corrections of crude positioning data are made.
>>
>> 2 - Can implementers of the geolocation API take advantage of vehicle
>> data to improve accuracy?  I think the answer is "yes".
>>
>> #2 Yes
>>
>> T.Hirabayashi
>>
>> ----- Original Message -----
>> It was my understanding, and Paul, please correct me if I'm wrong,
>> that we felt there should be changes to the geolocation API, that
>> those changes should be proposed to that group.  We want to avoid
>> duplicate APIs.  As far as accuracy goes, an OEM can implement the
>> geolocation API with much more accuracy in the vehicle because they
>> have more data available (gyro, rotation angle of the wheel, etc).
>> That however is not an API problem.  It's an implementation problem.
>>
>> So there are two questions that need to be solved:
>>
>> 1 - Is the geolocation API good enough for vehicles?  If not, we need
>> to work with that group to fix it.
>> 2 - Can implementers of the geolocation API take advantage of vehicle
>> data to improve accuracy?  I think the answer is "yes".
>>
>> On Tue, May 6, 2014 at 7:37 AM,  <ta-hirabayashi@kddi-ri.jp> wrote:
>>> Hi, Paul-san and Kevron-san
>>>
>>> While I do not notice it, a definition of the vehicle location
>>> information disappears in
>>> first draft spec.
>>>
>>> In the last f2f meeting, Urata-san pointed out the generic geolocation
>>> information (GPS-based)
>>> is not accurate enough. With gyro, vehicle speed, rotation angle of
>> the
>>> wheel and so on, most
>>> of car navigation diveces have higher accuracy (within 1 or 2 meters
>>> errors in any roads of
>>> Japan) than conventional devices such as a smartphone and tablet.
>>>
>>> In the case where the OS and the device which web apps are running on
>>> support generic
>>> geolocation APIs, it becomes difficult for us to acquire the accurate
>>> positioning data easily
>>> if vehicle location information should be not available as it is.
>>>
>>> In short, we thought that geolocation information and vehicle location
>>> information are distinct
>>> APIs in accuracy.
>>>
>>> Can you restore the definition of vehicle location information in spec?
>>>
>>> T.Hirabayashi/KDDI
>>>
>>>
>>>
>>
>>
>>
>
>
Received on Wednesday, 7 May 2014 17:34:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:53 UTC