Geolocation API Proposal

[Aaron Boodman-3]

Hi all,

We're adding an API to Google Gears that will allow an application to
obtain (with permission) the user's current location.

Here's our current design:

http://code.google.com/p/google-gears/wiki/LocationAPI

We think there's a lot of potential for interesting applications with
an API like this. Some examples would be recommendations for nearby
restaurants, turn by turn directions, or city walking tours.

What do people think of adding something like this to a future version of HTML?

Thanks,

- a

[Křištof Želechovski]

Dnia 05-03-2008, Śr o godzinie 23:36 -0800, Aaron Boodman pisze:

> Hi all,
>
> We're adding an API to Google Gears that will allow an application to
> obtain (with permission) the user's current location.
>
> Here's our current design:
>
> http://code.google.com/p/google-gears/wiki/LocationAPI
>
> We think there's a lot of potential for interesting applications with
> an API like this. Some examples would be recommendations for nearby
> restaurants, turn by turn directions, or city walking tours.
>
> What do people think of adding something like this to a future version of HTML?

The intersection of this interface with HTML is empty
and it will always be because it does not hook on anything to declare.  
It qualifies as a browser extension.

IMHO,
Chris

[Aaron Boodman-3]

On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski
<giecrilj@...> wrote:
>  The intersection of this interface with HTML is empty
>  and it will always be because it does not hook on anything to declare.
>  It qualifies as a browser extension.

How is it different than the HTML5 database API?

In any case, I wanted to post this here because this seems to be where
the right people are. But if you think there's a more appropriate
group to approach, let me know.

- a

[Aaron Boodman-3]

2008/3/6 Aaron Boodman <aa@...>:

> On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski
>  <giecrilj@...> wrote:
>  >  The intersection of this interface with HTML is empty
>  >  and it will always be because it does not hook on anything to declare.
>  >  It qualifies as a browser extension.
>
>  How is it different than the HTML5 database API?
>
>  In any case, I wanted to post this here because this seems to be where
>  the right people are. But if you think there's a more appropriate
>  group to approach, let me know.

After I wrote this, I realized the difference you might be thinking
about. We were imagining that when standardized, this API might live
at window.geolocation, clearly not google.gears....

The proposal actually mentions this in the top paragraph, but it might
not be clear enough.

Gears specifically avoids using the standard entry points (window,
document, etc) to avoid conflicting with browser native
implementations of the same standards. But from there down, we aim to
implement the same interfaces. So the gears geolocation object would
implement the same interface as the standard geolocation object, if
there was one.

Hope this helps,

- a

[Křištof Želechovski]

Dnia 06-03-2008, Cz o godzinie 08:30 -0800, Aaron Boodman pisze:
> On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski
> <giecrilj@...> wrote:
> >  The intersection of this interface with HTML is empty
> >  and it will always be because it does not hook on anything to declare.
> >  It qualifies as a browser extension.
>
> How is it different than the HTML5 database API?
>

A database is general-purpose
and this is an oracle for answering one question.

> In any case, I wanted to post this here because this seems to be where
> the right people are. But if you think there's a more appropriate
> group to approach, let me know.

How about defining a URI scheme to be used with XMLHttpRequest?
Where the URI will be 'about:geolocation' (or 'about:whereami')
and the result is text/xml (or text/gps+xml)?

I think browser extensions can easily hook into the about scheme
and intercept it.

Chris

[Brian Smith-19]

Aaron Boodman wrote:
> On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski
> <giecrilj@...> wrote:
> >  The intersection of this interface with HTML is empty  and it will
> > always be because it does not hook on anything to declare.
> >  It qualifies as a browser extension.
>
> How is it different than the HTML5 database API?

It isn't. See
http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg-
html5-specification-that-should-be-removed/

In particular, see Ian Hickson's comment. He already acknoledged that
this stuff doesn't belong in the HTML specification, and the only reason
that the current HTML 5 spec has so much junk in it is because nobody
else is writing seperate specs for these features.

Regards,
Brian

[Aaron Boodman-3]

2008/3/6 Brian Smith <brian@...>:
>  It isn't. See
>  http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg-
>  html5-specification-that-should-be-removed/
>
>  In particular, see Ian Hickson's comment. He already acknoledged that
>  this stuff doesn't belong in the HTML specification, and the only reason
>  that the current HTML 5 spec has so much junk in it is because nobody
>  else is writing seperate specs for these features.

I agree with Ian. This stuff doesn't belong in HTML, but this seems to
be a list where a lot of productive discussion is happening about
things that don't belong in HTML. So I thought I'd propose it here
first for feedback.

I'll move the proposal to the W3C WebAPI mailing list.

- a

[Neil Deakin-3]

Aaron Boodman wrote:

> 2008/3/6 Brian Smith <brian@...>:
>  
>>  It isn't. See
>>  http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg-
>>  html5-specification-that-should-be-removed/
>>
>>  In particular, see Ian Hickson's comment. He already acknoledged that
>>  this stuff doesn't belong in the HTML specification, and the only reason
>>  that the current HTML 5 spec has so much junk in it is because nobody
>>  else is writing seperate specs for these features.
>>    
>
> I agree with Ian. This stuff doesn't belong in HTML, but this seems to
> be a list where a lot of productive discussion is happening about
> things that don't belong in HTML. So I thought I'd propose it here
> first for feedback.
>
>  

This specification at http://www.whatwg.org/specs/web-apps/current-work/ 
wasn't originally about HTML directly, but about web application APIs,
for which these proposed features would be suitable. However, somewhere
along the way, that spec became about HTML5 instead and much of the
content contained in it was no longer directly applicable. The content
just hasn't been moved elsewhere.

I'm pretty sure that web APIs are still on topic for this list though.

[Robert Sayre-2]

2008/3/6 Aaron Boodman <aa@...>:
>
>  How is it different than the HTML5 database API?

It's not. Neither belongs in an HTML specification, but a charismatic
leader should be able to overcome this obstacle.

--

Robert Sayre

[Aaron Boodman-3]

I've posted this to the W3C WebAPI mailing list as well. Still looking
forward to feedback on the actual content of the proposal, in either
place.

Thanks,

- a

[Vladimir Vukicevic-3]

Hi Aaron,

On Mar 7, 2008, at 1:03 AM, Aaron Boodman wrote:

> I've posted this to the W3C WebAPI mailing list as well. Still looking
> forward to feedback on the actual content of the proposal, in either
> place.

I agree with the previously stated comments that this probably doesn't  
belong in HTML5, but, as you say, there isn't a better place to  
discuss it at the moment -- the people who would be interested  
intersect with the people who are interested in HTML5.

So, some feedback on the proposal... overall, I think that this API  
should be kept as simple as possible.  To that end, I would suggest:

- remove Address from Position; a separate API/spec/web service/
whichever can be used to turn a Position into an Address, without the  
awkward "requestAddress" boolean flag or similar.  I think this also  
removes the awkward gersLocationProviderUrls?  (If I'm understanding  
right, these are the services that would convert position->address?)

- altitude/horizontalAccuracy/verticalAccuracy should probably use -1  
if not available (using null can be awkward, since it'll become 0 in  
some contexts)

- Geolocation.lastPosition should, IMO, be the only interface here  
(probably Geolocation.position).  It already has a timestamp, so apps  
can determine when the fix is.  There's no need for watchPosition/
clear given that we have setInterval/setTimeout already.  An  
updateInterval can be added with the minimum interval between position  
updates, as a hint to applications how often it should be updating.

- I understand the desire for optionally obtaining a high accuracy  
fix; I would have that be a separate method for that.  For that, I can  
see a callback based interface would make sense, as acquiring the fix  
would take time.

- I would move heading/speed off into a separate Direction interface,  
though I don't have a strong opinion about that

So, I'd suggest:

interface Position {
   readonly double latitude;
   readonly double longitude;
   readonly double altitude;

   readonly double horizontalAccuracy;
   readonly double veritcalAccuracy;

   readonly bool valid; // true if the fix is valid and exists; if  
false, then an error message is available
   readonly string errorMessage;
};

interface Geolocation {
   readonly Position position;
   readonly int updateInterval; // in ms

   void requestHighAccuracyPosition (callback);
};

     - Vlad

 
 

[Shyam Habarakada]

Given that location may change with time, Position should (must?) also include the Time at which the particular value was produced. Optionally, it would also be good to have the Position describe 'how' the location was determined (GPS, cell-tower triangulation, etc.)

shyam

-----Original Message-----
From: whatwg-bounces@... [mailto:whatwg-bounces@...] On Behalf Of Vladimir Vukicevic
Sent: Monday, March 17, 2008 9:32 PM

<snip>

So, I'd suggest:

interface Position {
   readonly double latitude;
   readonly double longitude;
   readonly double altitude;

   readonly double horizontalAccuracy;
   readonly double veritcalAccuracy;

   readonly bool valid; // true if the fix is valid and exists; if
                        // false, then an error message is available
   readonly string errorMessage;
};

[Aaron Boodman-3]

Hi Vlad, thanks for the reply.

On Mon, Mar 17, 2008 at 9:31 PM, Vladimir Vukicevic <vladimir@...> wrote:
>  So, some feedback on the proposal... overall, I think that this API should
> be kept as simple as possible.  To that end, I would suggest:

I agree with the sentiment :)

>  - remove Address from Position; a separate API/spec/web service/whichever
> can be used to turn a Position into an Address, without the awkward
> "requestAddress" boolean flag or similar.  I think this also removes the
> awkward gersLocationProviderUrls?  (If I'm understanding right, these are
> the services that would convert position->address?)

Address was included because it can be a lot more efficient to do both
of these at the same time in one request than doing two separate
requests.

However, now that you bring it up, I think it might be more common to
only need to reverse geocode once, not continuously. So maybe that is
a point in favor of splitting the two functions apart.

The _gearsLocationProviderUrls is actually the services that convert
the "location signals" that the device has access to (cell ids, nearby
wifi nodes, etc) to a position. We expect that most UAs won't want to
allow applications to modify this list, but it's something that's
important to us, so we are OK with it as an extension.

>  - altitude/horizontalAccuracy/verticalAccuracy should probably use -1 if
> not available (using null can be awkward, since it'll become 0 in some
> contexts)

Altitude can be negative, so -1 won't do in that case. It would work
for the others, though, so we could just make altitude be zero and
verticalAccuracy be -1 in the case where vertical information is
unavailable. I'll make this change since others have expressed concern
with returning null from a numeric field.

>  - Geolocation.lastPosition should, IMO, be the only interface here
> (probably Geolocation.position).  It already has a timestamp, so apps can
> determine when the fix is.  There's no need for watchPosition/clear given
> that we have setInterval/setTimeout already.  An updateInterval can be added
> with the minimum interval between position updates, as a hint to
> applications how often it should be updating.

The reason for having an explicit watch/clear is for battery usage. We
don't want to have this thing running all the time just in case an
author asks for it. Having getPosition(), watchPosition() and
clearWatch() is intended to make it more apparent that the API starts
an expensive process and consumes resources.

Another reason for having getPosition() is that one of the major use
cases is getting the current location. For example, to find nearby
restaurants. With only lastPosition and no way to force an update, it
would be awkward to implement this kind of feature. You'd have to
first set updateInterval to the delay you're willing to wait, then
setTimeout() that long, then check the value.

Another design goal was to allow multiple javascript functions within
the same context to use the API without colliding with one another.
Having a single mutable updateInterval property would conflict with
this goal (although a workaround could be to create instance of the
geolocation object).

>  - I understand the desire for optionally obtaining a high accuracy fix; I
> would have that be a separate method for that.  For that, I can see a
> callback based interface would make sense, as acquiring the fix would take
> time.

Ok, there is also a need to get a default accuracy fix on demand, so I
will leave that part as is for now unless there are other issues.

>  - I would move heading/speed off into a separate Direction interface,
> though I don't have a strong opinion about that

I don't have a strong opinion about these properties. Other people had
asked that I add them so implementors didn't have to extend the spec
in undefined ways.

Thanks,

- a

[Benjamin West-2]

On Fri, Mar 7, 2008 at 1:03 AM, Aaron Boodman <aa@...> wrote:
> I've posted this to the W3C WebAPI mailing list as well. Still looking
>  forward to feedback on the actual content of the proposal, in either
>  place.
>
>  Thanks,
>
>  - a
>

What use cases are drive this proposal?
If the use case is for user agents to describe their geographical
location to applications, then one possible solution is to wield web
architecture, and use an HTTP header.
User agents might send something like:

    X-Agent-Lat: 1234123
    X-Agent-Lon: -2132362

This frames the problem in terms of an application being interested in
the properties of the client, instead of the client needing to know
about properties of the client so they can eventualy send a request to
an application with the same information.

That said, if the client does need to know, it might be easier to
simply give user script the ability to sniff and edit outbound headers,
with which you can build the proposed API.

Most of the features in you proposal seem to deal with geocoding, and
I've ignored that here.  The notion of sensitivity to time was
interesting, but I suspect HTTP headers would be adequate for that as
well.

Would a solution like this satisfy the requirements necessary for the
use cases that drive your proposal?

-Ben

[Maciej Stachowiak]

On Mar 19, 2008, at 8:44 PM, Benjamin West wrote:

> On Fri, Mar 7, 2008 at 1:03 AM, Aaron Boodman <aa@...> wrote:
>> I've posted this to the W3C WebAPI mailing list as well. Still  
>> looking
>> forward to feedback on the actual content of the proposal, in either
>> place.
>>
>> Thanks,
>>
>> - a
>>
>
> What use cases are drive this proposal?
> If the use case is for user agents to describe their geographical
> location to applications, then one possible solution is to wield web
> architecture, and use an HTTP header.
> User agents might send something like:
>
>    X-Agent-Lat: 1234123
>    X-Agent-Lon: -2132362
>
> This frames the problem in terms of an application being interested in
> the properties of the client, instead of the client needing to know
> about properties of the client so they can eventualy send a request to
> an application with the same information.

Geolocation is often an expensive operation in terms of power  
consumption, so it's better not to determine the answer until someone  
asks. Otherwise you needlessly drain the battery. Thus a script API is  
preferred to HTTP request headers since it is on demand.

  - Maciej

On Mar 19, 2008, at 8:44 PM, Benjamin West wrote:

> What use cases are drive this proposal?
> If the use case is for user agents to describe their geographical
> location to applications, then one possible solution is to wield web
> architecture, and use an HTTP header.
> User agents might send something like:
>
>    X-Agent-Lat: 1234123
>    X-Agent-Lon: -2132362
>
> This frames the problem in terms of an application being interested in
> the properties of the client, instead of the client needing to know
> about properties of the client so they can eventualy send a request to
> an application with the same information.

On Thu, Mar 20, 2008 at 8:16 AM, Maciej Stachowiak <mjs@...> wrote:
>  Geolocation is often an expensive operation in terms of power
>  consumption, so it's better not to determine the answer until someone
>  asks. Otherwise you needlessly drain the battery. Thus a script API is
>  preferred to HTTP request headers since it is on demand.

not to mention privacy concerns. automatically sending out the user's
coordinates just because their device supports gps isn't a good idea.

and do you send it to third party servers? should doubleclick be able
to automatically target their ads based on precise location?

[Shyam Habarakada]

> and do you send it to third party servers? should doubleclick be able
> to automatically target their ads based on precise location?

If the container page/site is able to access location via any of these mechanisms, there is little to nothing that the user-agent can do to prent that site from forwarding the information to an ad provider. In other words, the privacy concerns around location cannot be solved with just technical solutions and would require the implementation and adherence to policies that protect the end-user.

In many ways, this is no different to collecting the user's phone number or credit-card information via a web-form. The data needs to be handled in a trustworthy manner and the user must be able to easily understand how that information is used.

[Aaron Boodman-3]

On 3/21/08, Shyam Habarakada <shyamh@...> wrote:
> If the container page/site is able to access location via any of these mechanisms, there is little to nothing that the user-agent can do to prent that site from forwarding the information to an ad provider. In other words, the privacy concerns around location cannot be solved with just technical solutions and would require the implementation and adherence to policies that protect the end-user.

There's a difference between a page forwarding private info to third
parties and the third parties just getting the private info for free.

In our proposal, we mention getting user permission before sharing the
location details with the application, or even giving them an option
to provide only approximate location. That is another reason why it is
useful to have an explicit method to start the API.

Perhaps you could do something similar with the HTTP mechanism, but I
don't know how, exactly.

Another issue with the HTTP headers approach is that it doesn't seem
like a natural fit for offline-enabled web apps that want to use the
location info offline.


- a

[Shyam Habarakada]

> Perhaps you could do something similar with the HTTP mechanism, but I
don't know how, exactly.
>
> Another issue with the HTTP headers approach is that it doesn't seem
like a natural fit for offline-enabled web apps that want to use the
location info offline.

Right. I am not advocating the HTTP header mechanism. I was calling out the need for policy on top of which ever solution that ends up being used (particularly in the context of the doubleclick scenario that was brought up earlier).

[Ian Hickson]

Various proposals over the years have been made for a Geolocation API in
HTML5. Since the W3C has now started work on a Geolocation API
specification, I do not intend to add such an API to HTML5.

If you are interested in this work I recommend following this mailing
list:

   http://lists.w3.org/Archives/Public/public-geolocation/

As far as I can tell, all the feedback that had been sent to this list has
already been taken into account by that list, so I will not forward all
the feedback to the W3C as I sometimes do when feedback that was sent to
the WHATWG list becomes more relevant for another specification.

Cheers,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'