Guys:
I am confused. Is the Geolocation now available on the API?
How are users opting in to it on a tweet basis? or is the user
release later on?
Thanks,
Abir
On Sep 9, 7:13 pm, Mark Mason idtw...@gmail.com wrote:
For those using the iphone and tweetdeck, you can click the locate
icon
hi abir.
It's not yet live on Twitter - when it does become live, there will be
a setting available under each user's settings page to turn on the
ability for his or her API clients to annotate tweets.
On Sep 17, 2009, at 6:38 PM, Abir abstar...@gmail.com wrote:
Guys:
I am confused.
Raffi:
Thanks, that helps a great deal, we have created an app that our
business customers want to use, we will start testing with #94109
etc...and let you know when we go live, hopefully you guys will
release the geolocation soon. Abir
On Sep 17, 4:04 pm, Raffi Krikorian ra...@twitter.com
Raffi,
I fully understand the concern about privacy. To that end, here's
something you may want to consider:
Have application / web-site over-rides of the geo-code enable be
another option on OAuth. This way a user can control the creation of
geo-coding in their tweets on a finer grain basis.
hi jim.
that's definitely interesting - i don't think this will make it into
the first release, but i like the per-app permissions notion based on
oauth. it fits well on the grant permission read or grant
permission write options in oauth in general.
Raffi,
I fully understand the
For those using the iphone and tweetdeck, you can click the locate
icon and your iPhone: Long:Lat is updated on your profilie.location.
I am interested in GEO locate, so products can find you.
Example, You are on interstate driving or passenger, and it is after
3am, and you tweet...
Holiday Inn
hey abir.
Great discussion, the geolocation code is exciting opens up so many
possibilities.
thanks! we're excited as well.
1. Would you guys consider the geolocation code, opt-in on a tweet
basis? It would be an optional input on a tweet basis with the
default=off; This way users can
hi jim.
its only properly documented there (that will be fixed soon!), but all
user objects will have the geo_enabled element in it.
Raffi,
Is it only the account/verify_credentials method that will return the
geo_enabled sub-element in the user element, or all methods that
return a user
Raffi:
Great discussion, the geolocation code is exciting opens up so many
possibilities.
1. Would you guys consider the geolocation code, opt-in on a tweet
basis? It would be an optional input on a tweet basis with the
default=off; This way users can choose, Hey, I am walking down
market
Raffi,
Is it only the account/verify_credentials method that will return the
geo_enabled sub-element in the user element, or all methods that
return a user element?
While having only account/verify_credentials return it is better than
nothing, I would hope that all methods that return a user
My understanding is that all tweets will contain geo-location
information: if the information was supplied when the tweet was created,
that will be used; if no information was supplied, then the default
location from the user's profile will be used.
I, too, have several comments and questions.
My understanding is that all tweets will contain geo-location
information: if the information was supplied when the tweet was
created,
that will be used; if no information was supplied, then the default
location from the user's profile will be used.
actually - if there is no data passed in
hey jim.
1. the user.location is a completely separate entity (for now)
implies
that maybe sometime in the future it may be used, e.g., to provide a
default geo-coded location for a tweet. I would suggest that if the
user's profile location if ever geo-coded, that geo-code should be
added
13 matches
Mail list logo
