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 04:28:31 UTC