Re: GeoLocation API: 1. Source type of information / 2. Information from specific source type

Garvan Keeley <gkeeley@mozilla.com>, 2014-08-12 19:14 -0400:

> I think that without providing the information as to the origin of the location information:
> - people will not stop asking for this,
> - people will keep coming up with esoteric use cases.

Neither of those sound like super-compelling reasons for exposing the
origin of the location information..

And note that that Josef (the OP) wasn't just asking about exposing the
information -- he also asked "In some situations it would be great to get
the location information explicitly from a specific source type, mostly
GPS... Are there any plans to support fetching the location information
from a specific source by an additional parameter?"

It seems clear there is a significant risk of misuse in allowing Web
content to explicitly specify what location mechanism it wants to be used.
Web developers are not in the best position to make a determination for
users about what the optimal location-determination mechanism is across the
range of host devices that users might be using. The UA -- implemented
properly -- is a much better position to do that.

And the problem with just exposing the origin of the location information
is that once it's exposed, then more developers are inevitably going to
come back saying, That's great, now that I know that I'd like to be able to
control it from my Web app.

Another issue with even being able to expose it at all to begin with is
what Giri mentioned in his earlier response:

  I'll also note that location engines deployed in many mobile devices may
  rely on multiple sources in determining location, so a single source type
  would not always be optimal
  http://lists.w3.org/Archives/Public/public-geolocation/2014Aug/0004.html

As I understand it, the logic that some devices use for determining
location is not logic that's in the OS/platform software but instead logic
on the chipset on the device, and the chipset location logic, down at that
level, maybe using multiple sources to determine the location -- and the
platform APIs available on the hosting device may not even themselves
expose a means to control what location sources are used.

> There may not be a blanket use case for this that satisfies the geo
> working group. There is no guarantee that accuracy+highAccuracy indicate
> the location data source, yet many applications want to know the source
> of the location info.

If accuracy+highAccuracy are not causing the most-accurate means for
location determination on the hosting device to be used, then I think
that's a bug in the UA running on that device, and the proper way to
address that is for the UA vendor to fix their bug. The improper way to
address it would be for us to try to fix the wrong problem -- by trying to
give Web developers a way to work around the UA bugs (which would then give
the UA vendor even less incentive to fix their bug).

> Certainly, I have my use-case. For data collection purposes, I need to
> know/document the source of the geolocation information. GPS is a free
> system worldwide, and storing collected location data has no legal
> implications. Whether or not this is true for commercial location
> services, there are many who would want to steer well clear of
> commercially provided location sources due to legal risk. 
>
> Do I want to find out in country X, that large scale data collection
> based on commercially-provided locations has legal implications?

That does sound like a relatively esoteric use case..

> Are there specific applications where only GPS locations are considered
> valid over the long-term? Or that wifi-derived locations should be
> explicitly ignored due to their potential instability? 

Dunno but if we're building a platform for the future, and a platform that
allows Web content built in 2014 to continue working as expected in 2024,
2034, etc., without necessarily needing to be updated, it is short-sighted
to provide a means for Web developers to start hard-coding their Web
content to use location sources that just happen to be the most accurate
ones available this year.

GPS has its own significant problems, and it's imaginable that devices will
eventually commonly have a location-determination means that's better in
every way that GPS is now. And if/when such a new means becomes widely
available, Web content should not need to get updated to switch it to using
that new means due to the fact that the content was hard-coded in 2014 to
always just use GPS for determining the location.

> Another use case is for debugging, API users should be able to debug the
> location info themselves, not have to make guesses about the quality of
> the GPS signal causing an accuracy overlap with Network-based locations.
> I have the same problem this user does. I suspect anyone getting into
> commercial-level applications of geolocation will want to be able to make
> their own determinations about quality by combining the source with the
> accuracy. 

As with other debugging stuff, that seems like something that could just be
made available in the devtools features/environment of UAs, and that
wouldn't need to be exposed to Web content.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike