as some of you may have already noticed, we've started going through the first steps to get the geolocation API out our door. there are a few more steps in the process that i want to share with all of you.
if you start to pull status objects through the API, you'll notice that, for the majority of them, there is an empty <geo/> tag and for the user objects there is a <geo_enabled> tag that is set to false. i say most, because, if you pull my user object
for clarification: the <geo_enabled> will always be in a user object reflecting whether the user has opted-into the geolocation API. there will also always be a <geo> tag in the status object regardless of whether there is a location attached to the tweet or not. if there is no location, then the tag will be empty. if there is a location (as above), then the tag will be populated.
just to lay out a timeline -- we've deployed for internal testing, and soon we'll be turning this on for the general audience.
-- Raffi Krikorian Twitter Platform Team ra...@twitter.com | @raffi
> as some of you may have already noticed, we've started going through
> the first steps to get the geolocation API out our door. there are a
> few more steps in the process that i want to share with all of you.
> if you start to pull status objects through the API, you'll notice
> that, for the majority of them, there is an empty <geo/> tag and for
> the user objects there is a <geo_enabled> tag that is set to false. i
> say most, because, if you pull my user object
> for clarification: the <geo_enabled> will always be in a user object
> reflecting whether the user has opted-into the geolocation API. there
> will also always be a <geo> tag in the status object regardless of
> whether there is a location attached to the tweet or not. if there is
> no location, then the tag will be empty. if there is a location (as
> above), then the tag will be populated.
> just to lay out a timeline -- we've deployed for internal testing, and
> soon we'll be turning this on for the general audience.
Could you tell me if the existing Twitter radius advanced searching
will be tweaked to include those tweets with <geo> tags within the
enclosed location?
Thanks,
brian
On Oct 1, 3:52 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> as some of you may have already noticed, we've started going through
> the first steps to get the geolocation API out our door. there are a
> few more steps in the process that i want to share with all of you.
> if you start to pull status objects through the API, you'll notice
> that, for the majority of them, there is an empty <geo/> tag and for
> the user objects there is a <geo_enabled> tag that is set to false. i
> say most, because, if you pull my user object
> for clarification: the <geo_enabled> will always be in a user object
> reflecting whether the user has opted-into the geolocation API. there
> will also always be a <geo> tag in the status object regardless of
> whether there is a location attached to the tweet or not. if there is
> no location, then the tag will be empty. if there is a location (as
> above), then the tag will be populated.
> just to lay out a timeline -- we've deployed for internal testing, and
> soon we'll be turning this on for the general audience.
> On Oct 1, 9:52 pm, Raffi Krikorian <ra...@twitter.com> wrote: >> as some of you may have already noticed, we've started going through >> the first steps to get the geolocation API out our door. there are a >> few more steps in the process that i want to share with all of you.
>> if you start to pull status objects through the API, you'll notice >> that, for the majority of them, there is an empty <geo/> tag and for >> the user objects there is a <geo_enabled> tag that is set to >> false. i >> say most, because, if you pull my user object
>> for clarification: the <geo_enabled> will always be in a user object >> reflecting whether the user has opted-into the geolocation API. >> there >> will also always be a <geo> tag in the status object regardless of >> whether there is a location attached to the tweet or not. if there >> is >> no location, then the tag will be empty. if there is a location (as >> above), then the tag will be populated.
>> just to lay out a timeline -- we've deployed for internal testing, >> and >> soon we'll be turning this on for the general audience.
> Could you tell me if the existing Twitter radius advanced searching > will be tweaked to include those tweets with <geo> tags within the > enclosed location?
> Thanks, > brian
> On Oct 1, 3:52 pm, Raffi Krikorian <ra...@twitter.com> wrote: >> as some of you may have already noticed, we've started going through >> the first steps to get the geolocation API out our door. there are a >> few more steps in the process that i want to share with all of you.
>> if you start to pull status objects through the API, you'll notice >> that, for the majority of them, there is an empty <geo/> tag and for >> the user objects there is a <geo_enabled> tag that is set to >> false. i >> say most, because, if you pull my user object
>> for clarification: the <geo_enabled> will always be in a user object >> reflecting whether the user has opted-into the geolocation API. >> there >> will also always be a <geo> tag in the status object regardless of >> whether there is a location attached to the tweet or not. if there >> is >> no location, then the tag will be empty. if there is a location (as >> above), then the tag will be populated.
>> just to lay out a timeline -- we've deployed for internal testing, >> and >> soon we'll be turning this on for the general audience.
> as some of you may have already noticed, we've started going through
> the first steps to get the geolocation API out our door. there are a
> few more steps in the process that i want to share with all of you.
> if you start to pull status objects through the API, you'll notice
> that, for the majority of them, there is an empty <geo/> tag and for
> the user objects there is a <geo_enabled> tag that is set to false. i
> say most, because, if you pull my user object
> for clarification: the <geo_enabled> will always be in a user object
> reflecting whether the user has opted-into the geolocation API. there
> will also always be a <geo> tag in the status object regardless of
> whether there is a location attached to the tweet or not. if there is
> no location, then the tag will be empty. if there is a location (as
> above), then the tag will be populated.
> just to lay out a timeline -- we've deployed for internal testing, and
> soon we'll be turning this on for the general audience.
