W3C home > Mailing lists > Public > public-geolocation@w3.org > January 2009

RE: location providers

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Wed, 21 Jan 2009 16:00:30 -0600
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF10552DACF@AHQEX1.andrew.com>
To: "Erik Wilde" <dret@berkeley.edu>, <public-geolocation@w3.org>
Two sources, one result, how?

Alright.  Let's go with altitude.  I take each source and quantify its error.  The barometric altimeter is subject to pressure variations so it is off less than 200m, 95% of the time; I probably have to work this out ahead of time.  The GPS directly provides altitude uncertainty, which I scale to the same confidence.

I then have two values:

 BAlt = 300 +/- 200m
 GPS = 400 +/- 63.4m

As a device implementer, I can combine these using some sort of agreement algorithm (a+b/2 works fine, but there are definitely more sophisticated methods), OR I can pick the one that reports the smaller uncertainty.

Not easy, certainly.  But I wouldn't say that it's an intractable problem.

Cheers,
Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Erik Wilde
> Sent: Thursday, 22 January 2009 4:23 AM
> To: public-geolocation@w3.org
> Subject: location providers
> 
> 
> hello.
> 
> i am still not quite sure where to look up open issues, could somebody
> please point me to the right place?
> 
> a while ago i raised two questions about altitude, one was about the
> model of altitude (WGS vs. EGM), and the other was about GPS vs.
> barometric altitude. then we had the more general remark about the fact
> that there can be various location providers, and in fact both of the
> above issues could be summarized under that more general topic (even
> though WGS vs. EGM also could be regarded as a simple unit issue; but
> alas one that requires decidedly non-trivial conversions).
> 
> the comments on that list mostly seemed to argue that having multiple
> location providers (such as multiple altitude values, or even multiple
> locations) would complicate the API. and i guess there is no denying
> that this would be the case. however, i am still curious to hear from
> the proponents of the "there can only be one" (location) approach how
> they assume implementers of the APIs would deal with the problem of
> having to decide on for example "the altitude", when the device has two
> conflicting readings from GPS and barometric sensors.
> 
> it seems to me that having only one location is a simplification that
> either can take place in the API's implementation, or in the code using
> the API. there are advantages and disadvantages to both approaches. API
> simplicity is definitely an advantage of doing the simplification in
> the
> API's implementation, and i am still curious to hear how the API's
> implementation is supposed to do this.
> 
> cheers,
> 
> erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
>         dret@berkeley.edu  -  http://dret.net/netdret

>         UC Berkeley - School of Information (ISchool)
> 

------------------------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------------------------
[mf2]
Received on Wednesday, 21 January 2009 22:01:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:41 GMT