its up to the API client to send that extra data along -- its not in the tweet's textual content, if that is what you're asking. its metadata that is "attached" to the tweet.

so an opted-in user will have latLong data automatically attached to
her/his updates, taken from the browser/client W3c geolocation
capabilities or is it necessary to explicitly include them in the
message content?


Currently we geocode your user.location data to get an idea of where
you are. That gets attached to each tweet as it comes in, but its not
usually a representation of where you were when you actually sent the
tweet. The new functionality will allow you to geotag the actual
update without modifying the user.location field.

When it comes to search, we'll use both and give priority to the
tweet-level geotag.

Make sense?

Best, Ryan

Please could you advise on the differences between this and the current location based searching facility? Is the current location search based on the users location in their settings whilst this is a exact location for
each tweet?
On 20 Aug 2009, at 21:46, Ryan Sarver wrote:

We wanted to give you all a heads up on a cool new feature that is coming soon - Geolocation. The Geolocation API will give us the ability to attach geographic metadata to tweets to provide additional context with your update. Along with the option to tag updates, we will be able to search for nearby tweets and view the geo metadata in user timelines. The additional context allows for us to deliver more meaningful and localized experiences to users. We are also really excited about a unique facet of this release in that it will be API-only initially. This means that won't
surface the functionality and we look forward to seeing the new and
interesting experiences that will grow out of the ecosystem.

As part of our Geolocation efforts we will soon be publishing "Geolocation Best Pracitices" to guide everyone through issues like security and privacy as well as discussing some ideal experiences for users. Topics will include things like storage of location data, what to do with a user's historical data, how to present the concept of geotagging and more. The guide will create a framework from which we can address the challenges that come about
when dealing with something as sensitive as someone's location while
hopefully allowing everyone enough creative freedom to create their own
experiences around it.
is important to note that the feature is going to be strictly opt- in. It will be disabled until a user chooses to switch it on. We will provide a read-only attribute <geo_enabled> on the user object so an app can detect if the user has it
disabled and let them know if they need to turn it on before using a
geolocation feature.

While we can't provide an exact date for launch, you should plan on having a few weeks of development time before the new API is officially launched.
With that being said, lets get to it...

Example: Geotagging a Tweet
curl -d "lat=37.780467&long=-122.396762&status=I have arrived" -u user:pass

<?xml version="1.0" encoding="UTF-8"?>


<created_at>Tue Apr 07 22:52:51 +0000 2009</created_at>


<geo xmlns:georss="";>

<georss:point>37.780467 -122.396762</georss:point>




<name>Doug Williams</name>






We have also updated the wiki to reflect what the API will look like when it
launches, so check it out and let us know if you have any questions: ... ...
We'll also be in our recently announced IRC channel (#twitterapi
on if you want to discuss the announcement with the team.

PM, Platform Team

Raffi Krikorian
Twitter Platform Team | @raffi

Reply via email to