ok ok...
so i guess that in the search API json response we will see an extra:
"geo":
{
"type":"Point",
"coordinates":[37.78029, -122.39697]
}

for each element of the 'results' array.

BTW: I believe  "geo": null,

would be more manageable and formally correct then:

"geo":{}, when geolocation metadata are not available


On Sep 2, 11:02 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> 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?
>
> >> 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
>
> --
> Raffi Krikorian
> Twitter Platform Team
> ra...@twitter.com | @raffi

Reply via email to