Re: Vehicle Location Information

I think it is important here to understand your customer. As a developer
using the API, I don't want to see two APIs that are effectively the same
thing. It makes my code unnecessarily complicated. Personally, if I came
across this situation, I would immediately create an abstraction over them
to create one API.

There were a few comments about adding the source of the information to the
Geo API, which might be useful for developers. It seems like the
Positioninterface would have to updated to include something like
readonly
attribute DOMString *positionSource*; and possibly another value that is a
constant for the type of source: vehicle, mobile phone, tablet, etc.

Finally, just because phone positioning is bad now don't assume that always
be the case. There are companies working on technology, using existing
phone sensors minus GPS, to get very accurate positioning, e.g., within
buildings to find firefighters.


On Fri, May 9, 2014 at 8:52 AM, Rees, Kevron <kevron.m.rees@intel.com>wrote:

> 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>