Abraham,
Thanks for the tip on filing a bug request! I think that is the
way to go. As to your other suggestion, it obviously only works for
one side of the problem (Searching for who in SF is retweeted, rather
than who people in SF retweet), and unfortunately, even with
whitelisting, the REST API rate limit can run out more quickly than
the search API, especially if you feed it too many "disappointing"
queries. So it's immensely helpful to know that there is a more
direct way to communicate with Twitter's developers.
Thanks,
Matt
On Feb 6, 9:49 pm, Abraham Williams <4bra...@gmail.com> wrote:
> A work around would be to pull the original tweet information from the REST
> API and see if you still want to keep/use it.
>
> Did you check the issue tracker for an existing bug request? If none you
> could create one so Twitter can keep track of
> it.http://code.google.com/p/twitter-api/issues/list
>
> Abraham
>
>
>
> On Fri, Feb 5, 2010 at 00:00, Matt L <mlev...@gmail.com> wrote:
> > In the search API, if you query for "RT" in the San Francisco area
> > using the geocode parameter it returns both official retweets (ones
> > created by hitting the retweet button) and unofficial retweets
> > (retweets where either the user or the client has simply inserted the
> > text RT). Official retweets keep the location field of the original
> > tweet. Unofficial retweets take on the location of the user who
> > retweeted the message.
>
> > The problem I'm having is that this makes geolocation searches for
> > retweets from a certain area very confusing. It's impossible to
> > search for what/who people in a certain city, say San Francisco are
> > rtweeting the most. Users in San Francisco who use the official
> > retweet feature and retweet something from NY don't show up in a query
> > for San Francisco Retweets.
>
> > Likewise, if one was interested in who from San Francisco was being
> > retweeted the most, they would also be stymied b/c the results are
> > polluted with unofficial RT's that look text-wise like an official RT
> > (same message text format). So they would get a lot of results of San
> > Franciscans retweeting people from New York. The only way to check
> > against that would be to do a show/user lookup on the from_user, and
> > the rate limit on that API would be eaten up very quickly for any
> > persistant search.
>
> > Is there any plan to address these issues? Has anyone in the
> > development community found a work around?
> > Thanks,
> > Matt
>
> --
> Abraham Williams | Community Advocate |http://abrah.am
> Project | Out Loud |http://outloud.labs.poseurtech.com
> This email is: [ ] shareable [x] ask first [ ] private.
> Sent from Seattle, WA, United States
