Ben,
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
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 Twitter.com
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
"http://twitter.com/statuses/update.xml";
<?xml version="1.0" encoding="UTF-8"?>
<status>
<created_at>Tue Apr 07 22:52:51 +0000 2009</created_at>
...
<geo xmlns:georss="http://www.georss.org/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:
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-statuses%C2%A0u
...
http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0ve
...
We'll also be in our recently announced IRC channel (#twitterapi
on irc.freenode.net) if you want to discuss the announcement with
the team.
Ryan
PM, Platform Team
http://twitter.com/rsarver
