Geo type in geo object 2.0

[chompi]

Original author: hottbu...@gmail.com (August 02, 2011 14:39:31)

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: http://code.google.com/p/openrtb/issues/detail?id=38

[chompi]

From mich...@strikead.com on August 08, 2011 15:21:07
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.

[chompi]

From markus....@gmail.com on August 08, 2011 15:30:36
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.

[chompi]

From mich...@strikead.com on August 08, 2011 15:37:10
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

[chompi]

From markus....@gmail.com on August 08, 2011 15:44:47
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.