W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2008

[whatwg] Geolocation API Proposal

From: Vladimir Vukicevic <vladimir@pobox.com>
Date: Mon, 17 Mar 2008 21:31:52 -0700
Message-ID: <80CDB0E9-E48E-48AD-BAAD-1F54D724373D@pobox.com>
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

  
  
Received on Monday, 17 March 2008 21:31:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:40 UTC