[論文レビュー] GeoTextTagger: High-Precision Location Tagging of Textual Documents using a Natural Language Processing Approach

Shawn Brunsting, Hans De Sterck+2 more|arXiv (Cornell University)|Jan 22, 2016

Data Management and Algorithms被引用数 9

ひとこと要約

GeoTextTagger は、品詞タグ付け、固有表現抽出、および OpenStreetMap データ上の距離ベーススコアリングを組み合わせることで、テキスト文書の地理的タグ付けを高精度で行う自然言語処理アプローチを提案する。Wikipedia 記事においては、10パーセンタイル誤差が 490 メートル、中央値誤差が 54 キロメートルに達し、上位5つのスコアを考慮した場合、50% の記事が著者によって割り当てられた真の位置から 8.5 キロメートル以内に正しくタグ付けされた。

ABSTRACT

Location tagging, also known as geotagging or geolocation, is the process of assigning geographical coordinates to input data. In this paper we present an algorithm for location tagging of textual documents. Our approach makes use of previous work in natural language processing by using a state-of-the-art part-of-speech tagger and named entity recognizer to find blocks of text which may refer to locations. A knowledge base (OpenStreatMap) is then used to find a list of possible locations for each block. Finally, one location is chosen for each block by assigning distance-based scores to each location and repeatedly selecting the location and block with the best score. We tested our geolocation algorithm with Wikipedia articles about topics with a well-defined geographical location that are geotagged by the articles' authors, where classification approaches have achieved median errors as low as 11 km, with attainable accuracy limited by the class size. Our approach achieved a 10th percentile error of 490 metres and median error of 54 kilometres on the Wikipedia dataset we used. When considering the five location tags with the greatest scores, 50% of articles were assigned at least one tag within 8.5 kilometres of the article's author-assigned true location. We also tested our approach on Twitter messages that are tagged with the location from which the message was sent. Twitter texts are challenging because they are short and unstructured and often do not contain words referring to the location they were sent from, but we obtain potentially useful results. We explain how we use the Spark framework for data analytics to collect and process our test data. In general, classification-based approaches for location tagging may be reaching their upper accuracy limit, but our precision-focused approach has high accuracy for some texts and shows significant potential for improvement overall.

研究の動機と目的

• 文書内のテキスト的参照に正確な地理座標を割り当てる高精度な地理的タグ付けシステムの開発。
• 分類ベースのアプローチに起因する制限を克服すること。特に、分類サイズの制限と、精度の向上が鈍化する傾向にある点。
• 文書ごとに複数の場所をタグ付けできるようにする。テキスト内に複数の地理的参照がある場合に、それらを特定しスコアリングする。
• 構造化された Wikipedia 記事と非構造的な Twitter メッセージの両方で性能を評価し、現実世界の課題を反映する。
• スケーラブルなデータ処理と地図タグ付きデータセットの統合を可能にするために Apache Spark を活用する。

提案手法

• 最新の品詞タガーや固有表現認識器を用いて、テキスト内の候補となる場所参照を特定する。
• 各識別されたテキストブロックに対して、OpenStreetMap を知識ベースとして照会し、候補となる場所を取得する。
• 真の場所からの距離に基づいて、各候補場所に距離ベーススコアを割り当てる。グリーディー選択戦略を用いる。
• 繰り返し各テキストブロックに対してスコアが最も高い場所を選択することで、反復的改善により精度を向上させる。
• Wikipedia および Twitter の地図タグ付きデータのインジェスト、結合、前処理を効率的に行うために、Apache Spark を用いて大規模データセットを処理する。
• 特定の地域（カナダ、米国、オランダ、オーストラリア）からの地図タグ付きツイートを収集するために、Spark Streaming を改造し、関連性の高いトレーニングデータを確保する。

実験結果

リサーチクエスチョン

• RQ1 精度を重視した NLP アプローチは、分類ベースの既存の地理的タグ付け手法に比べ、局所化の正確性において優れていると言えるか？
• RQ2 特にテキスト内に複数の地理的参照がある場合に、本システムは1文書あたり複数の場所をタグ付けする上でどれほど効果的か？
• RQ3 明示的な場所の手がかりが欠如していることが一般的な短い非構造的テキスト（例：Twitter メッセージ）に対して、アルゴリズムの性能はどの程度か？
• RQ4 固定クラス分類モデルと比較して、動的で距離ベースのスコアリングシステムを用いることで、どの程度精度が向上するか？
• RQ5 Apache Spark のようなスケーラブルなデータ処理フレームワークは、地理的タグ付きの大規模で多様なデータセットのインジェストと統合を、地理的タグ付け研究において効果的に支援できるか？

主な発見

• 最高スコアのタグのみを考慮した場合、GeoTextTagger は Wikipedia データセットで 10パーセンタイル誤差が 490 メートル、中央値誤差が 54 キロメートルに達した。
• 1文書あたり上位5つのスコアを考慮した場合、Wikipedia 記事の 50% が著者によって割り当てられた真の位置から 8.5 キロメートル以内に正しくタグ付けされた。
• 短く非構造的で誤りの多いテキストであるにもかかわらず、Twitter データにおいても本システムは頑健な性能を示した。これは、実用的導入の可能性を示している。
• アルゴリズムの性能は、類似した Wikipedia データで中央値誤差が約 11 キロメートルだった従来の分類ベース手法よりも顕著に優れており、精度重視のアプローチへのシフトが顕著である。
• Apache Spark の使用により、大規模な地図タグ付きデータセットの処理が効率的に行えた。Wikipedia 記事とその場所タグを結合するには 80 行未満の Scala コードで十分だった。
• 本研究で使用されたデータセットは、過去の研究とは異なり、後発のデータダンプ（2015年6月対 2010年9月）を用いており、最終データセットにはリダイレクト記事が存在しなかった。これは、処理パイプラインのフィルタリングによる可能性が高い。