getcurrentPosition in oxide does not cause a wake up of the GPS

another site to test this on is https://www.where-am-i.net/

I'm not sure what Oxide is meant to do here - we query the location service via the qtpositioning API. There is no API for "waking up the GPS" AFAICT.

And to expand on this: even when requesting a single position with getCurrentPosition, oxide calls in to QGeoPositionInfoSource::startUpdates()¹. I wonder if there’s a bug in QtPositioning, or maybe incorrect documentation, as on my laptop (which doesn’t have a GPS chipset), when calling startUpdates() I’m getting a positionUpdated() signal almost instantly, with what seems to be the last known position, and its timestamp is 2016-03-24, i.e. 4 months ago. So it looks like it’s not even trying to get an updated position. Maybe it does, but prior to this it returns the last known position, and since we requested only one position (not regular updates), the source is shut down right away, thus not giving it time to get an actual update?

¹ https://doc.qt.io/qt-5/qgeopositioninfosource.html#startUpdates

Part of this is similar to bug 1551686.

In addition the fix proposed in that bug (which won't help in this case, though) we have two options:
1) completely get rid of caching in location-service
2) When the client specifies maximumAge as 0, oxide should keep discarding any position update which carries an old timestamp

I think that implementing #2 is a good thing regardless of #1, so I'd suggest that at least this part would be fixed in Oxide.

@Alberto: the maximumAge parameter is not exposed in the chromium content API. See https://cs.chromium.org/chromium/src/content/public/browser/location_provider.h.

Additionally, see my previous comment: I’m seeing the same issue on my laptop, which is not running the location service. It looks like QtPositioning will instantly return the last known position even when an actual update has been requested.

The issue I’m seeing on my laptop seems to be specific to the geoclue location plugin: the last known position is serialized on disk, and it’s always emitted at startup, regardless of whether an update was requested: https://github.com/qt/qtlocation/blob/dev/src/plugins/position/geoclue/qgeopositioninfosource_geocluemaster.cpp#L289

I just had a chat with Thomas, and it appears that the GeoPositionInfoSource as implemented in qtubuntu-sensors always returns the last known position first on purpose, before starting to request updates. This is similar to what the geoclue plugin does.

However it’s not clear that this should be happening: QGeoPositionInfoSource has a lastKnownPosition() method¹ that allows clients to query the last know position explicitly, so I don’t think a call to startUpdates() should return that last known position first. Instead clients should be calling lastKnownPosition() themselves to get a first approximation, and then call startUpdates() to get an updated position (and thus expect that the first response will be with an accurate position).

¹ https://doc.qt.io/qt-5/qgeopositioninfosource.html#lastKnownPosition

worth noting that the last known position isn't an estimate of where you are with low and decreasing accuracy (like a cell tower position is), where you have a rough position and an error radius, so you are in that circle with some kind of probability distribution on where you can expect to be found. It is a high accuracy position of where you have been at some point in the past, beyond a few minutes old it really is a very bad thing to store and return - it isn't an approximation of the current position.

Thomas, maybe we should drop my MP [1] and completely disable returning the LKP if it's more than a couple of minutes old, as Alan proposes, and instead add a LastKnownPosition property to the location service D-Bus interface, and query that in the qtubuntu-sensors's lastKnownPosition() method?

If my understanding is correct, please let me know if you'd welcome help to implement this.

[1]: https://code.launchpad.net/~mardy/location-service/old-location-1551686/+merge/293075

Right, but as long as the location service doesn’t return the last known location when updates were requested, it’s okay. There’s a specific method for querying the last known location, and it does what it says on the tin. Note that the last known position isn’t necessarily very accurate either. Position objects have attributes that convey the horizontal and vertical accuracy.

Last known position is almost always going to be a full house level GPS lock on the place where you last turned off a map application, probably the last destination you navigated to. Might also be a full GPS lock on the last place you took a photograph. This could be a problem for implementing things like http://pooperapp.com/ on Ubuntu Touch ;)
As long as getCurrentPosition doesn't just return LKP and calls startupdates() and returns the first position from that (I am a little unconvinced it calls startupdates at all, because then repeated calls would presumably eventually work and they don't?)

> I am a little unconvinced it calls startupdates at all, because then
> repeated calls would presumably eventually work and they don't?

startUpdates() is being called, but because oxide gets a position right away (the last known one), it calls stopUpdates(), which prevents the GPS from actually being woken up at all.

@Mardy: Any help is welcome :) I think we want to first drop providing the initial estimate altogether to get this bug fixed asap. We can then go ahead and investigate whether we want to expose the last known location to applications.

@Alan: I think it's still an estimate and we should provide that data to applications if they want to leverage it. Point being that it is up to them to filter/interpret the last known position in a sane way if they explicitly request it.

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package location-service - 3.0.0+16.10.20160811-0ubuntu1

---------------
location-service (3.0.0+16.10.20160811-0ubuntu1) yakkety; urgency=medium

  [ Alberto Mardegan ]
  * Don't sent last known position to new sessions (LP: #1604446)

  [ Scott Sweeny ]
  * Enable running location-service on Snappy Ubuntu Core

  [ Thomas Voß ]
  * Make sure that we are not racing with the timeout handler.

 -- Thomas Voß <email address hidden> Thu, 11 Aug 2016 08:27:10 +0000