# 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.