Geo type in geo object 2.0

[GoogleCodeExporter]

Background/Problem Description:
Publishers might not pass along lat/lng, and DSP wants to target at 
hyperlocal(true lat/lng) instead of reversed lookup by zip, or city.

Proposed Solution:
optional field "type" that specify what type of location geo object truly comes 
from

Original issue reported on code.google.com by hottbu...@gmail.com on 2 Aug 2011 at 2:39

[GoogleCodeExporter]

This makes sense. Whilst most SSP's will not pass along lat long if there is 
none available, it is possible that somebody out there will want to "help" a 
DSP and send back lat long reverse looked up from IP. So a type field would be 
perfect - "gps" or "lookup" or something like that.

Original comment by mich...@strikead.com on 8 Aug 2011 at 3:21

[GoogleCodeExporter]

I think values for a geo type field could be:
- gps: actual device lat/lng determined by a mobile device's GPS
- cell tower
- zip: zip code of the device location. We see this come through often on our 
network.
- city: city level location. we don't see this very often and maybe it is not 
necessary. 
- dma
- IP 
- area code: the centroid of the phone number area code. Obviously, this can be 
quite large. 

Original comment by markus....@gmail.com on 8 Aug 2011 at 3:30

[GoogleCodeExporter]

the key thing here is geo type - i.e. how was it obtained

zip, city, etc is often also looked up from IP, so type is crucial, as if it is 
- it will often not be very accurate

Original comment by mich...@strikead.com on 8 Aug 2011 at 3:37

[GoogleCodeExporter]

That is correct, type is crucial. There are use cases where the type can be 
city or zip, i.e., the lat/lng values were derived from a zip code or 
city/state values. E.g., using a weather application I can specify my location 
by typing city/state or zip code values. Those values are then used to make an 
ad request. 

Original comment by markus....@gmail.com on 8 Aug 2011 at 3:44