Hi Shaun,
The location information in the main API is in the user object
and is the string value the user set. That information is not geocoded
in any way so the format will be different and you'll need to handle
geocoding independently if it is needed. Like I mentioned, I'll look
into how we want to handle this.
Thanks;
– Matt
On Dec 17, 2008, at 08:11 PM, h0h0h0 wrote:
Thanks Matt! I will add the issue to the list.
Are you saying that the main API has location information in the
statuses?
On Dec 16, 11:06 am, Matt Sanford <[email protected]> wrote:
Hi Shaun,
We launched the location change along with some other changes
and
ran into some pretty serious performance issues. At first I thought
it
was the other code but it was in fact this location query causing the
trouble. We have a database change in progress that I am hoping will
let me roll this back out. Please do me a favor and add an issue to
our list (http://code.google.com/p/twitter-api/issues/list) so I
don't
forget to keep you updated.
We're also working on the next version of the API where we'll
return the same format for both the main API and search. I haven't
yet
figured out if/how we can include the data search has that the main
API does not (notably geocoded location and language code). Thanks
for
the reminder to look into that.
Thanks;
— Matt Sanford / @mzsanford
On Dec 15, 2008, at 09:35 PM, bugtank wrote:
Awhile back the Search API (Atom or JSON) would deliver a location
or
lat/long with each status update. I just picked up development
again
and found that the location attribute is now missing. Can this be
reimplemented? It would be great if the information was there
without
having to do a geolocation based search.
Thanks,
Shaun
