GeoClue2

Roman Gezikov rgesikov at gmail.com
Mon Apr 18 22:35:52 PDT 2011


On Tue, Apr 19, 2011 at 7:27 AM, Michael Leibowitz <
michael.leibowitz at intel.com> wrote:

> On Mon, 2011-04-18 at 11:49 -0700, Eckhart Wörner wrote:
> > Hi Michael,
> >
> > Am Sonntag, 17. April 2011, 23:35:16 schrieb Michael Leibowitz:
> ...
> > > The GeoClue API/design is not terribly efficient.  One ends up with
> > > several round-trips around DBUS for any position information.
> > > Additionally, using DBUS in this way leaks information all over the
> > > place.
> > >
> > > [...]
> >
> > I take that as a complement for my proposal, since it doesn't enforce
> D-Bus
> > usage between GeoClue2 and an individual provider anymore.
>
> It was certainly not criticism of your proposal, but rather criticism of
> GeoClue as it is now.
>
> > > The decision making powers and inputs to the Master Provider are too
> > > simple to give optimal results.  The master provider has no concept of
> > > latency or power consumption, providers have no basis to specify them,
> > > and clients have no basis to input their requirements for either.
> > > Furthermore the resources that providers may request are too course
> > > grained and rigid.  For example, a satellite position provider might
> not
> > > require network access to give information, but having it might enable
> > > assistance that greatly reduces latency or increases accuracy.> The
> GeoClue
> > API/design is not terribly efficient.  One ends up with
> > > several round-trips around DBUS for any position information.
> > > Additionally, using DBUS in this way leaks information all over the
> > > place.
> >
> > Why do you think an application knows better than GeoClue2 whether to use
> the
> > network or how much power consumption is acceptable? If the application
> knows
> > that the laptop is on battery, so does GeoClue2, if the application knows
> that
> > there is an internet connection, so does GeoClue2. If there was any other
> > essential piece of information which only the application has, there are
> > probably some design issues in your stack somewhere else.
>
> The application knows how long it plans to keep listening for location,
> which GeoClue doesn't know.  The application knows when it's willing to
> trade accuracy, latency, or power consumption.


I'd agree here that application knows what accuracy of position estimate it
needs. Some need to determine just a country or state user currently is in,
some need to remember position accurate to several meters (as in the example
with parking place below). But I am not sure if it's right approach to let
application to choose what providers to use. To me it seems correct if user
has a possibility to choose in systems settings if network/GNSS/IP/etc
positioning methods are allowed always/not allowed in roaming/prohibited and
applications just get position fixes with accuracy estimate for each and
decide if particular fix is suitable for their purposes ignoring the fix
otherwise.


>  Simply using accuracy as
> a proxy for power measurement doesn't give as much flexibility to choose
> the lowest power mechanism.  It also supposes that high accuracy methods
> are always the least power efficient.  This may not be true.
>
> Of course, I don't mean to imply that all this decision making power
> needs to be directed from the application to GeoClue.  Sometimes it is
> just enhancing the interfaces from GeoClue to the underlying system that
> would enhance its decision making powers.  Knowing more than "the system
> is connected to the internet" could be helpful.  Mobile systems often
> have power policies and connection policies that GeoClue could benefit
> from interfacing to.  Perhaps we can have facilities like these as more
> flexible than they are currently to resemble position providers more.
>
> > > The abstraction of providers also hides provider details.  This sounds
> > > like the facts of life and a non-problem, but it actually is a problem.
> > > There are my applications out there that want to display some detailed
> > > status of their position fix but also want to be able to support
> several
> > > positioning methods.  For example, an application might want to report
> > > the satellites in view if it's getting a GPS signal, but display the
> > > access points it sees for a wifi based position method.
> >
> > Except that this information serves no purpose in normal applications
> which
> > are just interested in position information. If you want to write an
> > application that shows your full GPS information, you should connect to
> gpsd
> > directly.
> > (I have seen few people who actually know how to interpret satellite
> > positions, which is a strong indicator that this is not something you
> want in
> > your average application's interface.)
>
> I disagree.  I think that not only is this something that could be
> trivially added, but isn't a niche thing.  I've seen many a mobile
> application that provide some information (useful or not) about their
> positioning method.  Additionally, the MeeGo API for location is the
> Qt-Mobility Location API.  It is designed to report satellite
> information for satellite based fixes.  At present, the implementation
> has to talk to both GeoClue and Gypsy to get this information.  This is
> suboptimal and it doesn't have to be so awkward to do so.
>
> It doesn't mean that GeoClue should expose NMEA streams to clients or
> that GeoClue should have lots of provider specific entanglements.  But
> would it be unreasonable for a provider to have a set of properties for
> the current status of their underlying mechanism?  The interpretation of
> these properties needs not be codified.  It could be as simple as an
> array of string->value pairs that a provider can offer to clients.
>

I agree here, including data structure proposal. The art will be to define
standard string keys common to all provides. At the same time, I'd propose
to move that from property of provide to property of position fix. Position
fixes come in real time and when application asks a provider about its
state, the state can change already from the one in which provider was
generating a fix.

>
> > > How do you specify accuracy, latency, or power requirements?  When
> > > creating the objects?  When querying them?
> >
> > Accuracy is specified as a property in the Provider object already.
> > (There are some issues in the old API which IIRC freely mixes accuracy
> and
> > precision).
>
> Right.  But I'm talking about the application side.  An application
> should be able to specify how accurate a fix it needs, how soon, and
> perhaps some power trade-off information that it can give.
>
> For example, if you are creating a mapping application, you want to
> start with the first available position from any source and as more
> accurate sources become available, get better and better position.
>
> Consider another case, where you need to do drop a pin so you can
> remember where you parked.  Having information that is accurate to
> within a few blocks is not helpful.  It's not worth firing up a cell
> tower triangulation system to give you position.
>

Good examples. And I'd propose here to provide all necessary information to
application (including accuracy) and let it decide if fix is useful or not.
For example an application may use fixes that are not accurate enough to
just show a position to show to the user that something is going on and then
when accuracy gets good enough start turn-by-turn navigation. I just thing
that we may end up with spending time adding a code that implements logic in
GeoClue and then applications need to tell "give me all".


>
> >
> > I'm not sure latency is a good idea to add - how do you filter available
> data
> > based on latency? How do you know there is less than 0.1 second delay in
> the
> > bluetooth connection between your gps and your laptop?
>
> But when you're in the process of resolving a position, you may start to
> get an idea of latent it's going to be.  For example, when you fire up
> the GPS and you're not seeing satellites- you know it might be a while.
> This could be useful information provided from the provider back to
> GeoClue.
>

Idea is good and that information would be useful probably. And problem is
that GNSS receiver  doesn't know that. It can be inside the building or
other shielded environment and even having all ephemerides and accurate time
it cannot predict when it makes first valid fix.


> > As already argued, GeoClue2 should have the same information about the
> power
> > situation as the individual application, and can therefore make the same
> > decisions.
> >
> > > I assume street is a freely encoded house number and street?
> >
> > I guess so. Address information has the same semantics as in the old
> GeoClue.
>
> I would advocate a structured address personally.  Getting this right
> with locale and etc is not always trivial.
>
> > > Also, how
> > > do you disambiguate ambiguous replies?
> >
> > I don't. This is a limitation I took over from the old API.
>
> Might you reconsider?
>
> ...
>
> > > What is to be configured?
> >
> > The address of your bluetooth GPS, activated providers, the server that
> is
> > used for cell triangulation, …
>
> This sounds like GeoClue is storing provider information on behalf of
> providers.  Why should GeoClue get entangled with such things?  In the
> current case, it does because Gypsy has no configuration of its own.  I
> see this as a fault in Gypsy- not a reason for GeoClue be a grab-bag of
> provider configuration information.
>

Yes, I agree. That should be properties of provider. Btw, in theory we may
have a provider that doesn't work with any HW, but gets data from other
provides and makes some better fix available to applications. As GeoClue
implements that 'provider plug-in' architecture it cannot no in advance what
provider will be connected.


>
> Cheers
> --
> Michael Leibowitz <michael.leibowitz at intel.com>
>
> _______________________________________________
> GeoClue mailing list
> GeoClue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/geoclue
>

Best regards,
Roman Gezikov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/geoclue/attachments/20110419/2648c604/attachment-0001.html>


More information about the GeoClue mailing list