About polling

[Georgios Diamantopoulos]

Hello,

Our application user base will largely consist of feature-phones - we
will be retrieving Zoom-level location data.

My questions regarding polling are:

- Obviously locating a feature-phone with zoom-level precision is a
premium feature. Does that mean that when the Polling API is used,
we'd get charged for each poll? Or only when we enquired on the actual
updated location of a user?

- In the .NET library, the callback of the PollingManager class (I
think that's what it was called, I don't have the code right here)
included Location information. In which case I assume that even if
Polling itself does not get charged, that the .NET lib actually
retrieves the updated location and the look-up is charged, before
delivering the data to the callback method. If my line of thought is
correct, is there another way to separate the polling result from the
actual updated location look-up and consequent charge?

Thanks
Georgios

[Eli Bishop]

hi, Georgios -

The Polling API will never generate any charges, but that's because it
never generates any new location requests through the carrier. That
means it's not really useful for feature phones, because feature phones
can't report their location unless the carrier asks for it.

By contrast, a smartphone with the Veriplace location agent installed
will report location data at intervals directly to our server, where it
can be picked up by the Polling API; that doesn't use the carrier's
location infrastructure, the phone is doing all the work, so we don't
get charged for it and neither do you. That's the use case that that
API was basically designed for.

best,
Eli

--
Eli Bishop
Wavemarket, Inc. / Location Labs
e...@location-labs.com

[Georgios Diamantopoulos]

Right, thank you.

Which brings me to my next questions:

- I tested it with two people, one was added as a feature phone (he
owns a smartphone really) and the other as a smartphone and installed
the software requested. However, when I tried to use Freedom mode on
the smartphone user, I got an exception the first time. I can't
remember the exact error but it didn't work straight away. Now, a few
hours later, it does - what can cause this?

- I don't quite understand the authorization model as it applies to
real applications (i.e. not developer mode). I understand the user
must create an account on veriplace.com but that doesn't seem very
practical. The scenarios we want to test are: a) the user signs up on
our service online and is at the same time guided to your website
(with some pre-filled fields like the phone number/e-mail which we'll
already have); on successfully completing registration and authorizing
our application to locate them, is brought back to our website and b)
the user does not sign up with veriplace.com at all but is asked to
verify that they agree to disclose their location (once only) using
SMS. Are these scenarios possible? If so, can you please provide some
guidance?

- With Zoom mode, with these two test users, I got "block-level"
accuracy (a few houses down) - judging from the address reported by
Veriplace that is. Can this accuracy be improved at all? Are there any
errors introduced by the longtitude/latitude => address lookup?

Thanks
Georgios

On Dec 29, 9:32 pm, Eli Bishop <e...@location-labs.com> wrote:
> hi, Georgios -
>
> The Polling API will never generate any charges, but that's because it
> never generates any new location requests through the carrier.  That
> means it's not really useful for feature phones, because feature phones

> can't report their location unless the carrier asksfor it.

[Eli Bishop]

Georgios,

See responses below:

On Dec 30 2010, 4:06 am, Georgios Diamantopoulos <georgi...@gmail.com>
wrote:

> Which brings me to my next questions:
>
> - I tested it with two people, one was added as a feature phone (he
> owns a smartphone really) and the other as a smartphone and installed
> the software requested. However, when I tried to use Freedom mode on
> the smartphone user, I got an exception the first time. I can't
> remember the exact error but it didn't work straight away. Now, a few
> hours later, it does - what can cause this?

Normally, after the smartphone location agent is installed, the first
thing it does is contact our server and post a location. It then
follows up with location updates at intervals - shorter intervals if
the location has been changing, longer intervals if it hasn't (to
reduce battery consumption). The updates are posted through a TCP
connection, so net access is required.

It's possible that at the time of that first contact, the phone either
couldn't get a location or was having a temporary connectivity problem
so it couldn't reach us. The location agent should detect this and
retry as needed-- which shouldn't take hours, but it's not clear to me
whether you're saying you continued to get errors for a few hours, or
you got one error and then retried a few hours later.

> - I don't quite understand the authorization model as it applies to
> real applications (i.e. not developer mode). I understand the user
> must create an account on veriplace.com but that doesn't seem very
> practical. The scenarios we want to test are: a) the user signs up on
> our service online and is at the same time guided to your website
> (with some pre-filled fields like the phone number/e-mail which we'll
> already have); on successfully completing registration and authorizing
> our application to locate them, is brought back to our website and b)
> the user does not sign up with veriplace.com at all but is asked to
> verify that they agree to disclose their location (once only) using
> SMS. Are these scenarios possible? If so, can you please provide some
> guidance?

Those are both basically possible, but I should clarify a couple of
things:
a) Interactive web authorization works more or less as you described,
but currently there's no way to pre-fill those form fields, so the
user would have to re-enter that information during the registration
flow.
b) The SMS opt-in process (see "Invitation API" in the Developer Guide
and SDK examples) does allow the user to create an account and grant
permission without doing anything on the web, but it has the following
limitations: it can only enable carrier-sourced location (that is, it
cannot provision a smartphone to use the location agent - phones would
have to be locatable through one of our supported carriers), and it
cannot create a one-time permission (although your application can
explicitly delete the permission after locating the user). Note that
in order to use SMS opt-in, you need to send us a support request to
enable it for your application - it is turned off by default.

> - With Zoom mode, with these two test users, I got "block-level"
> accuracy (a few houses down) - judging from the address reported by
> Veriplace that is. Can this accuracy be improved at all? Are there any
> errors introduced by the longtitude/latitude => address lookup?

For Zoom mode, we always provide the highest accuracy that's available
to us, but accuracy of GPS is highly variable. Every location we
return includes an uncertainty radius. If you're seeing a high
uncertainty radius, then the phone is not getting a very good GPS
fix-- or possibly cannot get a GPS fix at all, in which case we fall
back to cell tower triangulation, whose accuracy depends on the
density of cell service in the area and the signal strength.

The one exception, unfortunately, is AT&T iPhones, which cannot do
remote GPS requests at all due to a limitation in their network
infrastructure; that means that currently iPhones will always return
less-accurate cell tower triangulation locations. We're hoping to
address this in the future, either by AT&T changing their
configuration, or by providing an iPhone version of our location
agent.

Anyway, regarding street addresses: If you're getting a radius of 100
meters, then the phone could be anywhere within 100 meters of the
returned latitude/longitude, and the address lookup will necessarily
be approximate. On the other hand, if you're getting a radius of 10
meters, and you know that the phone is exactly where we say it is by
latitude/longitude (i.e. if you plug those coordinates into a map),
but the reported street address is wrong-- then there could be a
glitch in the reverse geocoding service that we use. But it's more
likely that the accuracy problem is in the original location data,
rather than in the street address lookup.

best,
Eli