OK my app basically provides a way for users to come to the site, and
look at local tweets by city/state combo (I have to include state
because a lot of states have identical city names).

I WAS using the search API feature with geocodes to get local tweets
and it worked PERFECTLY minus of course the limited data set problem
-- but I obviously can't do that due to API call limits and having
(hopefully :)) thousands of users per day searching for local tweets
repeatedly.

Now according to Raffi Krikorian

"search, however, attempts to use other signals to determine where the
tweet
is, and will attempt to return "more" tweets when you use its "search"
parameter.  it does not, however, expose those signals in the search
results."

Well, not having knowledge of those "other signals"....... leaves me
with pretty much nothing but the Location field to parse for location
information. Right now I'm working on a DB search scheme to match
likely city, state combos but other than that do you guys see any
other methodology I may be overlooking??

The location field, unless it contains lon/lat coordinates, is a mess
of garbage, nonsense, mispelled names, and a host of other useless
noise.

The ones that have lon/lat information in the tweet location field are
perfect because then I can do my own radius calculations locally. But,
for example, out of a 1.5 million tweet sample only 100,200 of those
had lon/lat coordinates :(

Reply via email to