On Mon, Feb 29, 2016 at 10:12 PM, Felipe De La Puente
<fdelapuente@xxxxxxxxx> wrote:
I think that the weak link here is the GNSS assistance mechanism used in
ubuntu.
Having a good assistance method the time to first fix should be within
seconds or worst case a couple of minutes. Am I right?
Yup, that's true. We achieve ~15 seconds for a first fix using the
Here positioning provider,
and ~3 minutes for a full fix on average in our testing scenarios.
If the system is able to achieve <1min time to first fix, then you don't
need to give the last known position to the client apps anymore.
Now, let's say you are inside a building, then you need an alternative
method to determine your location, like using visible cell towers or
hotspots.
We rely on the "currently-connected-to-cell" and visible wifis to
carry out the positioning if you have Here enabled.
We do not consider visible cell towers for multiple technical reasons,
none of them unsolvable but open work items.
Please note that we remove the "currently connected to cell" from the
list of measurements after 60 seconds as the modem firmware used to
have issues when doing a phone call while driving. Switches of the
currently active cell were not reported correctly, and the result were
wrong positions. I can provide a silo for testing purposes that has
the heuristic removed easily.
Cheers,
Thomas
Best Regards,
Felipe.
On Mon, Feb 29, 2016 at 5:46 PM, Alan Pope
<alan.pope@xxxxxxxxxxxxx> wrote:
Hi Thomas,
On 29 February 2016 at 15:35, Thomas Voß <thomas.voss@xxxxxxxxxxxxx>
wrote:
> On Mon, Feb 29, 2016 at 12:38 PM, Alan Bell
<alanbell@xxxxxxxxxx> wrote:
>> it isn't really about that, it is about providing less broken location
>> data
>> to applications that ask for it. The current situation is that if an
>> application requests location data it gets given random coordinates of
>> somewhere you may have been to in the last week or so.
>
> Hmmm, I'm surprised by that statement. The service hands out the last
> known good location, together with a timestamp
> and the accuracy aged out. If applications fail to handle the
> respective data correctly, it is not the service at fault here.
>
I spent a week in Germany last week. At lunch time we wandered outside
from the exhibition centre and opened HERE maps to find a nearby kebab
shop (don't ask). Ogra pulled out his MX4 running rc-proposed and used
HERE to find a local shop and navigate to it. Our destination seemed a
ludicrous distance away from our current location, until we noticed
the current location on the map was actually the hotel we left some 5
hours previously. Cue a few moments of stabbing to refresh the app to
make it realise we've moved (quite a bit as it happened).
While this may be "Working As Designed", it's not "Working in a
meaningfully useful way". Having a location which is "aged" by over
half a working day is pretty useless on a mobile device. Other
platforms don't do this (in my experience), neither should we, battery
life be dammed, frankly. I want the map to show me where I am now, not
where I ate breakfast sometime in the past.
>> Then it thinks about
>> refreshing the location and refining it over the next few
minutes or so
>> if
>> the application is one that asks where you are again and again. If it
>> could
>> take a peek at the satellites every so often then it would enable
>> several
>> additional classes of application and would be less broken for things
>> that
>> only ask once.
>>
>
> That's incorrect. The service keeps on delivering updates to
> applications that have requested continuous location updates.
Then there is a bug in the platform. The browser (in which HERE runs)
is a default app and the location service is also pre-installed. There
is an issue here which clearly need nailing as I'm certain we're not
the only 3 people in the world to experience this.
Cheers,
--
Alan Pope
Community Manager
Canonical - Ubuntu Engineering and Services
+44 (0) 7973 620 164
alan.pope@xxxxxxxxxxxxx
http://ubuntu.com/
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
