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

On Fri, Aug 21, 2009 at 4:06 AM, Ben Eliott<> wrote:
> Hi,
> 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?
> Thanks,
> Ben
> 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.
> 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"?>
> <status>
> <created_at>Tue Apr 07 22:52:51 +0000 2009</created_at>
> ...
> <geo xmlns:georss="";>
> <georss:point>37.780467 -122.396762</georss:point>
> </geo>
> <user>
> <id>1401881</id>
> <name>Doug Williams</name>
> ...
> <geo_enabled>true</geo_enabled>
> ...
> </user>
> </status>
> 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.
> Ryan
> PM, Platform Team

Reply via email to