W3C home > Mailing lists > Public > public-geolocation@w3.org > October 2008

Location providers and competition

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Tue, 21 Oct 2008 01:19:42 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF104FC9AAD@AHQEX1.andrew.com>
To: <public-geolocation@w3.org>
Hi All,

It seems like the geolocation API is a ripe ground for competition.  From the perspective of a vendor that provides location-related products, it is obvious that competition between location providers is inevitable.  The role of a standard in arbitrating competition is an interesting one.  So I pose the question: what will the geolocation API do to facilitate competition?

To get the cognitive juices flowing, here are the potential providers I can see, based on my own limited perspective (I'm sure that others can think of more options):

 - manual entry (user types lat/long or picks a point on a map)

 - SkyHook (as seen in Mozilla Labs Geode)

 - autonomous GPS on the device (slow, but effective)

 - SUPL SET-initiated positioning (an open mobile alliance standard)

 - HELD (network-based location using the model developed by the IETF; disclaimer: I am one of the authors of this document)

 - DHCP (host configuration with the option from RFC 3825; I'd recommend against this, but it's an option nonetheless)

 - 3GPP mobile originated location request using control plane positioning (see ETSI TS 123.271)

 - methods based on public cell-tower location databases (there are plenty of these on the 'net)

 - QR code or RFID scans (with location by value or reference)

Assuming that multiple providers exist, how does a browser arbitrate between multiple location providers?  Serial execution is likely to guarantee that the solution fails miserably.  Is this decision made by the user?  Is this decision exposed on the API?

This question might not directly relate to the geolocation API, but a decision needs to be made whether it does or not.  If the choice is exposed on the API, then it had best not be too difficult to manage.  Otherwise, I'd argue that implementation guidelines are necessary to ensure that a consistent experience is maintained between browsers.

Different providers have different traits - accuracy, times, ability to provide altitude or speed estimates.  Evidently the enableHighAccuracy flag was intended as a hint to the browser, but this goes a little deeper.

This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
Received on Tuesday, 21 October 2008 06:20:29 UTC

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