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 <[email protected]> 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
> [email protected] | @raffi
