- From: Rees, Kevron <kevron.m.rees@intel.com>
- Date: Fri, 9 May 2014 08:52:38 -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 Fri, May 9, 2014 at 2:45 AM, ALDRIC LOYER <aldric.loyer@mpsa.com> wrote: > Hi All, > Thank you very much for this very interesting discussion. Before addressing this during our meeting on Tuesday, let me give you my opinion about that : > First of all, I confirm that the position acquired by a Smartphone differs from the "Enhanced position" acquired and computed by the vehicle. When driving, and if available, the second one should be used. > But in the same time, from most application developers point of view, I guess they don't really care who provides the position (the smartphone, a GPS peripheral, the Vehicle, a fake GPS, ...). And then, they would probably prefer a single API description for all kind of sensors, that is to say the one from Geolocation API specification. > Anyway, the choice of the best positioning sensor (Vehicle GPS or Smartphone GPS) must be done by someone, and probably not by the Smartphone maker... > In consequence, in the same way as a "Fake GPS application", we have to provide a way to develop a kind of a "Car Enhanced GPS application" that will overwrite the smartphone GPS position with the vehicle acquired GPS position. The way this works in android is to provide a "mock position service". This service provides data through the standard geopositioning APIs in android, including the w3c geolocation implementation as well as native APIs. I have an app that does this with bluetooth GPS units because android doesn't support bluetooth GPS by default. This is how you solve Hirabayashi-san's use-cases: The OEM (or 3rd party) would provide an app for the phone that would provide a mock positioning service that uses vehicle data. No extra or additional APIs required to make this "just work" for ALL position-aware applications that might run on the smartphone. If we provide an additional API in the vehicle spec, existing position-aware apps that aren't using the vehicle API will be broken. The user will go through tunnels and will be very frustrated. It's a bad user-experience. -Kevron >Of course, this kind of application is at a lower level than any "position based customer application", but this one will need a specific API to get the "Vehicle acquired GPS position" which is, for me, still in the W3C Auto Web API scope. > I'll check how this topic has been addressed in MirrorLink. > 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 : Tatsuhiko Hirabayashi [mailto:ta-hirabayashi@kddi.com] > Envoyé : vendredi 9 mai 2014 06:18 > À : 'Paul Boyes' > Cc : 'Marc Lapierre'; '박종선(Justin Park)'; 'Rees, Kevron'; public-autowebplatform@w3.org > Objet : RE: Vehicle Location Information > > Paul-san, Kevron-san, Justin-san > > I very much appreciate your comments. > > In Japan, there are many tunnels and road grid among buildings is > complicated > in the urban area, in which interruption of GPS signals arises frequently. > > Simple GPS solution is not available for us, because the error of > positioning > sometimes ranges from dozens of meters to several hundred meters. > > In such situations, Japanese car navigation devices with high accuracy > have been developed so far. > > I also know that there are various methods to improve the accuracy of > positioning > by GPS and other strategies. > > I have no intention to define a separate API for each source and method. > I understand that a single API is an ideal. > > My suggestion is just that we would like to get the simple mechanism and > the opportunity > so that accurate location data in a vehicle could be available for BYOD. > > Further to our discussions, shall we provide vehicle location data as a > kind of vehicle data > for the phone, especially for emergency purposes in Japan's road > circumstances?? > > I will arrive at the Tower hotel on the evening (around 17:00) of 21st, so > after that > and in the morning of 22nd I can discuss this topic. > > Thanks. > > T.Hirabayashi/KDDI > > > -----Original Message----- > From: Paul Boyes [mailto:pb@opencar.com] > Sent: Friday, May 09, 2014 4:50 AM > To: ta-hirabayashi@kddi-ri.jp > Cc: Marc Lapierre; Tatsuhiko Hirabayashi; 박종선(Justin Park); Rees, > Kevron; public-autowebplatform@w3.org > Subject: Re: Vehicle Location Information > > Hirabayashi-san, > > Would you give examples as to how the Vehicle Location API might look > comparing it to the Geolocation API? Hard and fast examples would really > help me. > > Will you be attending the W3C Automotive Business Group meeting on Tuesday? > If so, we should discuss. Let’s definitely discuss at the face to face. > > Thanks, > > Paul J. Boyes > -------------------------------- > Mobile: 206-276-9675 > Skype: pauljboyes > > > > > On May 8, 2014, at 11:22 AM, <ta-hirabayashi@kddi-ri.jp> <ta- > hirabayashi@kddi-ri.jp> wrote: > > > Hi, Marc-san > > Thank you for your question and comment. > My comments are in line below as shown in simbols of ### > > > - first, by using the existing geolocation APIs, which would return > the > geolocation data from the smartphone's GPS antenna > > ### Right. > > - second, using an automotive specific API, which would return the > geolocation data of the vehicle's antenna through the remote > connection > > ### As I mentioned first, most of Japanese car navigation devices > have > already higher accuracy (within 1 or 2 meters) in Japan than a > smartphone, > because error correction of GPS data are done by using gyro, > vehicle > speed, > rotation angle of the wheel and so on > There may be a vehicle having a same function for accurate > positioning. > > We thought that geolocation information and vehicle location > information > are distinct data in accuracy. > > Under such circumstances, we would like to use the higher accurate > location > data after error corrections are completed, for web-apps of > smarthone, > not GPS data in smartphone itself. > > For this purpose, vehicle location API should be separately defined > as > an > API other than geo-location API. > > Best regards, > > T.Hirabayashi/KDDI > > ----- Original Message ----- > Hi Tatsuhiko-san, > > To clarify, am I correct in assuming that you are suggesting that > two > separate APIs are for the use case where there is a remotely > connected > smartphone which would like to access geolocation of the vehicle, > and > that > separate APIs will allow the smartphone to access two sources of > geolocation information: > > - first, by using the existing geolocation APIs, which would return > the > geolocation data from the smartphone's GPS antenna > - second, using an automotive specific API, which would return the > geolocation data of the vehicle's antenna through the remote > connection > > In the case where the HTML5 application is running directly in the > vehicle's infotainment system, I would assume that both sets of > APIs > would > return the same information. > > Is this the idea behind the separate vehicle geolocation API, or is > there > another use case for this? > > > Best regards, > > > Marc Lapierre > Team Lead HMI, Engineering Services > QNX CAR Platform > > T +1 613 591 0931 ext. 24889 > F +1 613 591 3579 > E mlapierre@qnx.com > > QNX Software Systems Limited > A subsidiary of BlackBerry > > > > > > > > On 2014-05-08 10:01 AM, "Tatsuhiko Hirabayashi" <ta- > hirabayashi@kddi.com > > > > wrote: > > > > Hi, Paul-san, Justin-san > > Thank you for your comments. > > I thought that in consideration of 2 use-cases, WRT in the > phone side > would provide > web-apps geo-location data which is generated by phone > itself. > > Although accurate location data has been calculated in a > vehicle or > built-in type navigation > device, smartphone apps cannot access these data in geo- > location API. > > If the previous vehicle location API will be available, we > can get > accurate data outside the > phone in place of geo location data which is generated by > phone itself. > > This issue is not implementation detail in a web layer. > I believe that vehicle location API will be very simple > solution for 2 > use-cases. > > Your understandings would be appreciated. > > T.Hirabayashi/KDDI > > > > -----Original Message----- > From: 박종선(Justin Park) [mailto:jongseon.park@lge.com] > Sent: Thursday, May 08, 2014 9:33 PM > To: 'Paul Boyes'; 'Tatsuhiko Hirabayashi' > Cc: 'Rees, Kevron'; public-autowebplatform@w3.org > Subject: RE: Vehicle Location Information > > I’m on the same page with Kevron’s opinion that it is an > implementation > issue rather than API definition. > > > > From what I understand, it’s hard to find a reason > to have additional > location API in our specification. > > > > Unfortunately, I’m not quite sure about the meaning of the > sentence > > > below. > > > > > > “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.” > > > > In consideration of 2 use-cases, WRT in the phone side > would provide > > > geo > > > location data which is generated by phone itself or comes > from vehicle. > > I have no idea what makes it difficult to access accurate > data and how > additional location API makes it easier. > > I'd be thankful if Mr. Hirabayashi could elaborate a little > bit further. > > > > Regards, > > Justin > > > > From: Paul Boyes [mailto:pb@opencar.com] > Sent: Thursday, May 08, 2014 7:53 AM > To: Tatsuhiko Hirabayashi; 박종선(Justin Park) > Cc: Rees, Kevron; public-autowebplatform@w3.org > Subject: Re: Vehicle Location Information > > > > Hirabayashi-san, > > > > This is a great topic as these type of relationships to > other specs > > > will > > > come up repeatedly. Thanks for posting. > > > > Perhaps a vehicle location api is needed and the group > should > > > definitely > > > discuss. That said, it seems to me that we are discussing > the > implementation layer. In its introduction, the Geolocation > API > (http://dev.w3.org/geo/api/spec-source.html) states the > following: > > > > "The Geolocation API defines a high-level interface to > location > information associated only with the device hosting the > implementation, > such as latitude and longitude. The API itself is agnostic > of the > underlying location information sources. Common sources of > location > information include Global Positioning System (GPS) and > location > > > inferred > > > from network signals such as IP address, RFID, WiFi and > Bluetooth MAC > addresses, and GSM/CDMA cell IDs, as well as user input. No > guarantee > > > is > > > given that the API returns the device's actual location." > > > > Here are some thoughts and questions: > > > > ―Does the Geolocation API give the web developer the > information they > need to develop apps at the web layer in a vehicle? If not > what is it > missing (this may tell us what a vehicle location api might > need)? > > ―The Geolocation API has the concept of accuracy as part > of the > Coordinates interface. > > ―There is nothing stopping the implementer of the > Geolocation API from > using vehicle data in their implementation to make it more > accurate. > > ―The Vehicle Information API is geared to application > developers at the > web layer not lower implementation layers. > > ―The Vehicle Information API and the Geolocation API can > be used in > conjunction with each other to implement higher level > application > functionality, > > > > I suggest we do the following: > > > > ―Add a section to the Vehicle Information API laying out > it’s > relationship to the Geolocation API. In my opinion, it > would say for > geolocation information use the Geolocation API. > > ―Ask the Geolocation group to add statement the “common > sources” > > > section > > > of the introduction about using vehicle information. > > > > Justin, > > > > I would love to hear your thoughts if you have time as well. > > > Paul J. Boyes > > -------------------------------- > > Mobile: 206-276-9675 > Skype: pauljboyes > > > > > > > > On 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. > > > 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 Friday, 9 May 2014 15:53:07 UTC