「位置」をチェックインしたら「場所」が違う–こんなミスマッチが最大で40%もある位置サービスの現状
Foursquareなどの位置対応サービスでチェックインしようとしたら、その位置にあるお店や施設などがシステムに10ぐらいしか登録されてない、ということがよくあるね。たとえばニューヨーク市のGrand Central Terminalは、Foursquare上にたくさんの場所がある。Grand Central Terminal自身もあり、32番線、34番線、108番線などのホームもある。駅内にあるBlimpiesやHudson News、それに”5時22分着の特急”なんてのもある。後者は、場所というより、動いている列車だ。もっと細かく、たとえば”中央口の時計の近くの切符売り場の前”と言いたいときもあるが、たいがいの場合はGrand Central Terminalをチェックインするだけで十分だ。
しかし登録されている場所が少ないという問題は、Foursquareなどの場所データベースに必ずある。モバイルマーケティングのPlacecastによれば、10回のチェックインのうち4回は、位置データベースにその場所がないこともある。Placecastは2か月前に、位置アプリデベロッパのためのMatchAPIというものを立ち上げたが、これは、位置データベース上の場所の重複（一つの場所が複数の位置に対して使われている）という問題の解決を助ける。この無料APIの登録ユーザは、およそ200の位置対応サービスだが、彼らがこのAPIに通す2000万の位置のうち、約150万は間違いまたは重複だという。ミスマッチ率は、いちばん低いサービスで8%、いちばん高いところでは40%だった。ユーザが場所をアップロードしたり識別するタイプのサービスでは、当然ながらミスマッチの率は高い。
一つの位置には一つの場所、という正規化を行うことは、必ずしも解決にはならない。Grand Central Terminalの32番ホームにいても、友だちに32番ホームにいるよと伝えたいときと、単純にGrand Centralにチェックインするだけでいいときがある。その位置を全体的にカバーする場所（例: グランドセントラル駅）がデフォルトであるべきだし、それはどの位置対応サービスでもそうなっているべきだ。前にも主張したが、最終的には業界全体で協力して作る場所のオープンデータベースが必要であり、すべての位置対応サービスがその普遍的な場所データベースを使うようになるべきだ。各サービスは、各社まちまちの場所データ作りという苦労から解放されて、自分の本来のサービスだけに力を注げばいい。
（翻訳：iwatani(a.k.a. hiwa)）
近日開催のイベント
