Bug 29989

In the case where the client has set a minimum time period when he wants update info, then it could make sense. The master provider could cache the data and then when the timer expires it would send everything cached up to that point.

The longer the timeout the larger the inaccuracy will be, and indeed in mobile devices you simply trade accuracy for battery life, with an acceptable margin of error. When battery life is not an issue, this thing probably won't make sense and you probably want to get every single update, when they happen (like in a car navigation system).

One possible different approach would be to implement the cache system in the QT Mobility bindings side. A custom QGeoPositionInfoSource class could be implemented, which would provide a QGeoPositionInfo structure with the cached data.

It would be very good to combine position and velocity as they form one positioning fix. Address shouldn't be there since it takes some time to find out (if it is needed) and would thus delay delivery of the fix.

Basically you get both at the same time in today's solutions. Having separate messages is a relic from gypsy. 

If these are delivered separately, on Qt side you have combine them together, which means delay and/or uncertainty which parts together form the fix.

I agree that position and velocity should be merged.

I also agree with Martti that position and address shouldn't be merged because whilst the position is known as precisely as possible at any instant, the address will need to be calculated or looked up, which means that it should be delivered asynchronously from the position signals.

Thus, changing the title to remove the address signal.

From the GPS perpsective Ross sums it up nicely. It looks a bit different for, say access point or cell positioning:
* address data may be available at the same time as position, two
  queries/signals are as unnecessary as with velocity and position on GPS.
* velocity will probably never be available from anything else than GPS.


> If these are delivered separately, on Qt side you have combine them together,
> which means delay and/or uncertainty which parts together form the fix.

I'm not really against these changes, but I am wondering what the real need is: what exactly needs the specific combination of position signal + velocity signal?

(In reply to comment #5)
> * velocity will probably never be available from anything else than GPS.

Maybe it depends on the platform? I suppose that in an IVI or something similar there  could have other sources of speed, and combine that with an electronic compass, and you get velocity at a given time, but this time without a position fix, which might come form something else, especially when GPS is unavailable (in a city, with tall buildings, or driving in a tunnel).

> > If these are delivered separately, on Qt side you have combine them together,
> > which means delay and/or uncertainty which parts together form the fix.
> 
> I'm not really against these changes, but I am wondering what the real need is:
> what exactly needs the specific combination of position signal + velocity
> signal?

The Qt Mobility Location API has basically signals only for updated position. You can add on other info to these position signals, like speed and heading (velocity). But there is no mechanism to provide the additional info without a location, so in that API the provider must always provide a fix first and foremost.

See http://doc.qt.nokia.com/qtmobility-1.0-tp/qgeopositioninfosource.html#positionUpdated for info on the positionUpdated signal which delivers a QGeoPositionInfo (http://doc.qt.nokia.com/qtmobility-1.0-tp/qgeopositioninfo.html) as the payload.

Bug 27891 is the other side of the coin: not everyone sees geoclue as a GPS-wrapper... now we just need to figure out a solution that fills both needs -- at least I think that should be the goal.

Longer-term, s single "Location" interface with a single changed-signal would solve both problems but we'd have to deal with client needs and provider capabilities inside it. I realize Stefan and Martti consider separate messages "a relic from Gypsy" but originally we (Iain and me) figured interfaces would be a clean way to do handle the basic needs/capabilities. It's possible that this was a bad decision.

> The Qt Mobility Location API has basically signals only for updated position.

Right, I realized this after sending the message... I don't like the cached/delayed signal idea either, that's just wrong for the clients that actually use constant GPS location.

I have been thinking more on this in the meantime and also agree that there are several geo information details that can be provided by various providers at varying rates. In that sense the qt api is a bit limited. Thus the aggregation should probably done at that level.

It could cache all kind of details and whenever it gets a position update, aggregate and send them.

Read through this bug as part of analyzing what and how the QtLocation satellites and positioning for MeeGo should be done. Currently I think the way to go is to create a sufficient combining logic for the velocity and positioning data at Qt binding level.

Closing all bugs on old geoclue. If your bug still applies to new geoclue, please do re-open, I really don't have time to go through each and every bug and evaluate separately. :( Apologies for any inconvenience caused by this change.