Will this apply to direct messages too?
On Aug 21, 12:44 pm, Ryan Sarver <rsar...@twitter.com> wrote: > 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 > > On Fri, Aug 21, 2009 at 4:06 AM, Ben Eliott<ben.apperr...@googlemail.com> > 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 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