W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2013

Re: Indoor API in new charter?

From: Michael van Ouwerkerk <mvanouwerkerk@google.com>
Date: Tue, 26 Nov 2013 17:30:30 +0000
Message-ID: <CAF40kP40yyMDWNQnE2tbCWQZ2Lv_NO=i0nHuTknpeaDspvZWPw@mail.gmail.com>
To: "Mandyam, Giridhar" <mandyam@quicinc.com>
Cc: Dominique Hazael-Massieux <dom@w3.org>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Thanks Gridhar! Could you give use any information about how the Qualcomm
hardware determines floor and venue id? How accurate is it? E.g. if I'm
standing in a mall with many venues, what is the probability of it
selecting the correct nearest venue? At what distance from the venue does
it trigger? How many venues does it globally recognize (coverage)? Maybe
that's not all public info, so maybe you cannot share it. But it would give
insight into the type of API we could usefully design for Geolocation v2.

I think at Google we would need to contact a server, passing lat,lon, and
alt. Something like the Google Places API:

That way it's possible to get much more detail about the place, but at the
cost of a network request. So place information would not be part of the
Position object, it would be acquired separately by the web app, not by the



On Thu, Nov 21, 2013 at 3:28 PM, Mandyam, Giridhar <mandyam@quicinc.com>wrote:

> There already has been a specific Android class extension for indoor
> location in existence:
> https://developer.qualcomm.com/docs/snapdragon-sdk/reference-api/com/qualcomm/snapdragon/sdk/location/QCLocationManager.html
> .
> -Giri
> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: Thursday, November 21, 2013 1:54 AM
> To: public-geolocation@w3.org
> Subject: Indoor API in new charter?
> Hi,
> The proposed new charter for the group currently has a deliverable for
> indoor location:
> http://lists.w3.org/Archives/Public/public-geolocation/2013Nov/att-0003/Proposed_Geolocation_Working_Group_Charter.htm#deliverables
> During discussions last week in TPAC, there was unclarity on:
> * whether indoor location needed anything special in the API (i.e. only
> required browsers to use whatever location technology is available
> indoors)
> * if it did, whether there was sufficient experience with these
> specificities to proceed with standardization; for instance, there doesn't
> seem be to an official iOS or Android indoor location API
> I would be interested in getting views on these two considerations.
> If any of the two is confirmed, I think including indoor location in the
> new charter as a Rec-track deliverable is probably premature; in which
> case, I would suggest we keep the topic on, but as "use case and
> requirements" deliverable, rather than for an API.
> Thanks,
> Dom
Received on Tuesday, 26 November 2013 17:31:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:07 UTC