【121日目】Django×Tweepy_位置情報とツイートデータの構造（pages / items）について
昨日までの続きです。
今日は「位置情報が付与されたツイート」を取得したくて調べた結果と、「ツイートデータの構造」に関してまとめます。
位置情報が付与されたツイートについて
まず、位置情報を活用した機能を実装するのはやめにします。
理由は以下です。
ユーザー側で意図的に位置情報を付与しないと位置情報は付与されない（ツイートの度に自動で付与されているわけではない）
位置情報が付与されたツイートは全体1-2%程度という情報が多かった
つまり、あんまり分析に耐えうるデータになっていないのです。
ユーザーが意図的に付与した情報で、かつ全体に対する割合が低いので、とても偏ったデータであることが想定されます。
それでも、、例えば飲食店など、位置情報が付与されやすいものが分析対象であればやる価値はあるかもですが、今回はそうではないのでやめることにしました。
ツイートデータの構造について
大量のツイートを取得しようとすると、取得数の上限が100件であることが問題になります。それを解消するための「ページネーション」という手法？がよく紹介されていました。
ただ、これがどういう構造になっているのかよく分からなかったので自分で色々と動かして学びました。
結論として、ツイートデータは以下の構造で取得されています。
これまでの記事でご紹介してきたコードでは、Item数を指定して制限をかけていました。例えば以下なら1ページをリクエストして、10件のツイートデータを取得する、という形になっています。
tweets = tweepy.Cursor(api.search_30_day, label='test1', query='検索ワード').items(10)ただし、これだと最大で100件までしか取得できないので、それ以上にツイートを集める必要がある場合は、itemsではなくpagesで指定する必要があります。例えば以下の場合は最大で30ページ取得できます。
tweets = tweepy.Cursor(api.search_30_day, label='test1', query='検索ワード').pages()ただしこの30ページというのは30リクエストを意味しています。つまり、めちゃくちゃツイートされている検索ワードで実行してしまうと、30リクエスト、3,000ツイートを取得してくることになります。私は今朝これをやってしまい、一撃でリクエストの上限数を12％も食いました・・・
ちなみに検索ワードは「ケンタッキー」です。みんなケンタッキー大好きすぎる・・・笑
そのためリクエスト数を節約したい場合はpagesにページの上限を指定してあげればよいです。以下の場合だと2リクエストで済みます。
tweets = tweepy.Cursor(api.search_30_day, label='test1', query='検索ワード').pages(2)無料で試している時は上限が気になると思うので、皆さんご注意ください。
tweepyを理解する手助けになれば幸いです。
ここまでお読みいただきありがとうございました！