[twitter-dev] Re: the new retweet feature might break my app
In the examples that are shown in the developers preview for the RT api these where prefixed with RT, was this done on purpose or did this change after the examples where made public? On Nov 11, 6:48 pm, John Kalucki wrote: > Search is aware of the need for a retweet operator, but the feature is > unscheduled and completely speculative. > > In any case, Search will become less useful for this sort of > repetitive complete corpus search. If you need all of something, or a > sample of something, you should be moving to the Streaming API > wherever possible. > > -John Kaluckihttp://twitter.com/jkalucki > Services, Twitter Inc. > > On Nov 11, 9:39 am, Yaniv Golan wrote: > > > > > Thanks John, > > this means that my app won't work anymore! > > streaming api makes my life very hard > > hence i need to search for links and then extract them, this is very > > resource demanding to do on the fly > > while with search API i can search then extract and then search again > > i could use queue system but then again i will lose all the real time > > fun > > will there be a filter in the search api for retweets like there is > > for links? > > that could solve all my problems > > > On Nov 11, 7:22 pm, John Kalucki wrote: > > > > Retweets do not modify the original text in any way. There is no RT to > > > search upon. > > > > There is a feed of all public retweets on the Streaming API, but it is > > > not generally available. Instead, you can request a sample of all > > > statuses and filter for those that are retweets. > > > > -John Kaluckihttp://twitter.com/jkalucki > > > Services, Twitter Inc. > > > > On Nov 11, 8:58 am, Yaniv Golan wrote: > > > > > oh... > > > > that's cool :) > > > > Thanks i really got wםrried for a sec > > > > > On Nov 11, 5:08 pm, Walter Smulders wrote: > > > > > > With the retweet function the status text will still be prefixed with > > > > > RT > > > > > > On Nov 11, 11:59 am, Yaniv Golan wrote: > > > > > > > Hi > > > > > > I'm using twitter search API to search statuses with retweet > > > > > > expressions (e.g RT VIA) with the link filter > > > > > > i search the documentation over and over but i can't find any > > > > > > solution > > > > > > to what will happen after the retweet will rollout completely (the > > > > > > retweet expressions as we knew them will disappear and there is no > > > > > > other API method to much my search criteria) > > > > > > what should i do to get all the retweets that contains links? > > > > > > thanks
[twitter-dev] Re: Finding tweets from Zipcode
You can by getting the latitude and longitude for the zipcode and then use search with those coordinates in specified radius. You can also do it trough the streaming api with tweets containing geo location information. On Nov 12, 8:07 am, dhaval wrote: > Hey all > > Is there any way I can get all the tweets from a zipcode? Eg:- all the > tweets from 10019 > > Let me know if I can do that. > > Thanks
[twitter-dev] Re: the new retweet feature might break my app
With the retweet function the status text will still be prefixed with RT On Nov 11, 11:59 am, Yaniv Golan wrote: > Hi > I'm using twitter search API to search statuses with retweet > expressions (e.g RT VIA) with the link filter > i search the documentation over and over but i can't find any solution > to what will happen after the retweet will rollout completely (the > retweet expressions as we knew them will disappear and there is no > other API method to much my search criteria) > what should i do to get all the retweets that contains links? > thanks
[twitter-dev] Proposed changes to the local trends api
Hi fellow developers! When I saw the local trends api preview that was released yesterday I felt it wasn't really in line with the old trends api and inconsistent. So I made this drawing with my vision on the trends api, I hope you can all figure this out. If not just reply here and i'll try to explain it further. I talked about this on IRC with Raffik and he is willing to make changes that reflect this layout. And let something know if you got an even better idea. The drawing: http://twitpic.com/p0fwj
[twitter-dev] Re: expanded geocoding APIs
You could look at the Streaming API, more specifically: http://stream.twitter.com/1/statuses/sample.json. I don't know if this is a full stream of new public tweets or not (could someone specify this for me too please?), but it looks like a nice start... On Nov 2, 10:37 am, Kal wrote: > Hi everyone. I've been working on a twitter app with a small team for > about half a year now that is focused on geocoding and mapping of > tweets. Work so far has been done with dummy data, since the geocoding > APIs aren't available yet. I've been looking at how I might use the > upcoming APIs to access real twitter geo data, but it doesn't seem > possible to get the data that we need. > > Right now in our test application we have a database of fake tweets > that include lat/lon coordinates. This allows us to do queries for > specific regions, periods of time, etc. For example, we need to know > how many tweets were made within a certain rectangular area (someone's > mobile screen) within the last hour, week etc. Right now I can get all > of the tweets in one query, and then perform clustering to display > them on a map. I cannot see anything in the upcoming APIs that allows > me access to this sort of data. > > I've looked > athttp://search.twitter.com/search.json?geocode=40.757929%2C-73.985506%..., > but that only gives tweets within a certain radius, and only up to 100 > at a time. This isn't practical when I need to identify on a map where > perhaps thousands of tweets have happened over an extended time > period. I've looked elsewhere and can't see anything that would help > our situation, save the firehose. I know it says don't contact twitter > about access, they'll contact you, but there is no way to launch our > app without access to it. > > I would love to hear any suggestions people might have as to how I > could perform the queries I need to perform, or perhaps alternative > techniques I have neglected to think of. > > Thanks, > Kallin Nagelberg
