- From: Andrei Popescu <andreip@google.com>
- Date: Wed, 29 Jun 2011 14:18:46 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- Cc: Steve Block <steveblock@google.com>, Doug Turner <doug.turner@gmail.com>, Anne van Kesteren <annevk@opera.com>, Lars Erik Bolstad <lbolstad@opera.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
On Wed, Jun 29, 2011 at 12:02 PM, Dominique Hazael-Massieux <dom@w3.org> wrote: > Le mercredi 29 juin 2011 à 11:45 +0100, Andrei Popescu a écrit : >> Not sure I fully understand this: how would the UA know it got close >> to the relevant location solely by looking at WiFi and CellIDs? >> >> Wouldn't it have to use the network to get a lat/long back? > > Presumably "only" when CellID detection change; more specifically, an > optimization could be that having determined that the user is in a given > cell (far from the destination), there is no point in checking again > until the user gets into a new cell (even if there are e.g. multiple > Wifi networks change along the way). > > Since cells can get get pretty large, this can be a significant > battery/network optimization. > Yep, this would reduce the number of requests to the server, although that can be even further reduced as Steve suggested. Whether the gain is big enough to warrant adding a new API just for one usecase...that's something I'm not totally sure. Thanks, Andrei
Received on Wednesday, 29 June 2011 13:19:10 UTC