店舗や施設の位置データを使ってみたいと思ったとき、最初の候補になるのがPOI(Point of Interest)データです。カフェ、コンビニ、病院、ホテル、観光施設など、人が関心を持つ場所を、名前、緯度・経度、カテゴリ、住所、電話番号、Webサイトといった属性と一緒に扱えます。こうしたデータは地図表示や店舗検索だけでなく、商圏分析、不動産、旅行サービス、レコメンドなどにも活用できます。
現在は、Foursquare Open Source Places、Overture Maps、OpenStreetMap(OSM)など、誰でも試せるPOIオープンデータがあります。ただ、実際に使おうとすると「結局どれから触ればよいのか」が分かりにくいと感じることが多いはずです。私は普段、店舗・施設データを使った分析やデータ整備に関わっており、所属するデジタルアドバンテージではチェーン店舗データベース「ロケスマDATA」も提供しています。この記事では、まず誰でも同じように試しやすい3種類のオープンデータに絞り、実際に東京・吉祥寺駅周辺で取得・比較した結果も交えながら、「最初の1つをどう選ぶか」を整理します。
POIとは?
POIは、ひとことで言えば「場所のデータ」です。例えば、あるカフェについて、店舗名、カテゴリ、緯度・経度、住所、電話番号、Webサイトといった情報が1件のレコードとしてまとまっているイメージです。地理空間データというと難しそうに聞こえますが、まずは「緯度・経度を持った店舗・施設データ」と考えると分かりやすいと思います。

図1 POIデータのイメージ:店舗・施設を名前、カテゴリ、位置、住所などで表現する
POIデータを使うと、「駅から500m以内にカフェはいくつあるか」「この街にはどんな種類の施設が多いか」「あるチェーンはどのような街に出店しているか」といった分析ができます。地図サービスだけでなく、データ分析やアプリ開発の入口としても、とても扱いやすいデータです。
まず結論:最初に試すならどれ?
最初に結論を書くと、3つのデータにはそれぞれ特徴があるため、絶対的な一番はありません。ただし、「最初に1つ試す」という目的なら、かなり選びやすくなります。私は、SQLでPOIを分析してみたいならOverture、道路・建物・公園なども含めて地理情報を扱いたいならOpenStreetMap、Placesとして整理された店舗・施設データを多く扱いたいならFoursquare、という考え方が分かりやすいと思います。

図2 最初に試すPOIオープンデータを選ぶためのフローチャート
特に「とりあえずPOI分析を試してみたい」という場合、個人的にはOvertureが入りやすいと感じています。公開GeoParquetをそのまま扱え、アカウント登録なしでも始めやすく、DuckDBなどと組み合わせてSQLで分析しやすいためです。一方で、POIだけでなく地図全体の情報を生かしたいならOpenStreetMap、Placesデータとして多くのレコードを扱いたいならFoursquare、というように、目的によって向く入口は変わります。
3つのPOIデータをざっくり比較する
まず、大まかな違いを表にまとめます。
| Foursquare | Overture | OpenStreetMap | |
|---|---|---|---|
| 主な性格 | Placesデータ | Placesを含む地図データ | コミュニティ地理データ |
| アカウント | 必要 | 公開GeoParquetは不要 | 基本不要 |
| 主な取得方法 | Iceberg / DuckDBなど | GeoParquet / DuckDBなど | Overpass / OSMnxなど |
| 分類方法 | 独自カテゴリ | taxonomy |
key=valueタグ |
| POI以外の地理情報 | Places中心 | 建物・交通などもある | 道路・建物など非常に豊富 |
| 向いている入口 | 店舗・施設データ分析 | SQLによるPOI分析 | GIS・地図との一体利用 |
この表で重要なのは、3つともPOIデータではあるものの、「同じものを同じルールで収録しているわけではない」という点です。FoursquareやOvertureはPlacesデータとして比較的扱いやすい構造を持っていますが、OpenStreetMapは店舗データ専用ではなく、道路、建物、公園、河川、駅なども含む巨大な地理データベースです。そのため、OpenStreetMapではamenity=cafeやshop=convenienceのようなタグから必要な地物を取り出す使い方になります。
実際に吉祥寺で比べると、かなり違った
理屈だけでは違いが見えにくいので、実際に吉祥寺駅周辺の同じ範囲で3データを取得してみました。今回の条件で得られたレコード数は、Foursquareが7,176件、Overtureが3,666件、OpenStreetMapが1,194件でした。数字だけを見るとFoursquareが最も多く見えますが、ここから「Foursquareが最も網羅的である」とまでは言えません。各データで何をPOIとして扱うか、どのような条件で取得しているかが異なるからです。
さらに、名前、住所、電話番号、Webサイトがどの程度入っているかも調べました。今回の吉祥寺実験では、名前はFoursquareとOvertureで100%、OpenStreetMapで80.2%でした。住所はFoursquareが95.4%、Overtureが99.7%、OpenStreetMapが11.9%、電話は63.5%、87.7%、7.8%、Webサイトは35.6%、78.0%、11.8%という結果でした。
| 属性 | Foursquare | Overture | OSM |
|---|---|---|---|
| 名前 | 100.0% | 100.0% | 80.2% |
| 住所 | 95.4% | 99.7% | 11.9% |
| 電話 | 63.5% | 87.7% | 7.8% |
| Webサイト | 35.6% | 78.0% | 11.8% |
今回の条件では、Overtureは住所・電話・Webサイトなどの属性が比較的多く入っていました。一方、OpenStreetMapは今回のPOI抽出条件では属性の存在割合が低く見えます。ただし、これは品質や正確性のランキングではありません。ここで見ているのは「その属性に何らかの値が入っている割合」であり、最新性や正確性を検証した値ではないためです。また、OpenStreetMapはそもそも店舗専用データではなく、より広い地理情報の一部としてPOIを扱っていることにも注意が必要です。
それぞれ、どんなときに選ぶ?
Foursquare Open Source Placesは、店舗・施設をPlacesデータとして扱いたいときに分かりやすい選択肢です。今回の吉祥寺実験では3データの中で取得レコード数が最も多く、カテゴリ情報もほぼ全レコードに入っていました。一方で、利用にはPlaces Portalのアカウントとトークンが必要で、最初に少しだけ準備が必要です。「店舗・施設のPlacesデータをまとまった形で扱いたい」「POI件数をある程度多く持ちたい」という場合に有力な候補になります。
Overture Mapsは、Placesだけでなく建物や交通など複数の地図テーマを公開しているプロジェクトです。PlacesデータはGeoParquetとして公開されており、今回利用した方法ではアカウントやAPIキーは不要でした。特にDuckDBとの相性がよく、巨大なGeoParquetをローカルからSQLで扱いやすい点が魅力です。今回の吉祥寺実験でも、住所・電話・Webサイトのpresenceが比較的高く、「まずPOIを分析してみたい」という入口としてかなり扱いやすいと感じました。
OpenStreetMapは、少し性格が違います。店舗データ専用ではなく、道路、建物、公園、駅、河川など、さまざまな地理情報をコミュニティが編集する巨大な地理データベースです。そのため、「POIだけを一覧で取得する」というより、必要なタグを決めて地物を抽出する使い方になります。今回の吉祥寺実験では件数や属性presenceだけを見るとFoursquareやOvertureほど多くありませんでしたが、道路や建物なども一緒に扱えることが大きな強みです。地図アプリを作る、OSMをベースにGIS処理をする、POI以外の地理要素も組み合わせたい、といった用途なら最初からOpenStreetMapを選ぶ理由があります。
プログラムからも意外と簡単に触れる
地理空間データというと専用GISソフトが必要そうに見えますが、小規模な実験であれば普段のPython環境からでも十分に始められます。例えばOpenStreetMapなら、PythonのOSMnxを使って次のように取得できます。Google Colabで試す場合は、最初にOSMnxをpip installでインストールしてください。
# Google Colabなどで未導入なら実行
# !pip install -q osmnx
import osmnx as ox
tags = {
"amenity": True,
"shop": True,
}
pois = ox.features_from_bbox(
(139.574, 35.699, 139.586, 35.708),
tags=tags,
)
# 取得件数を表示
print(f"取得件数: {len(pois):,}件")
# 例: 取得件数: 1,117件
# 名前のあるカフェを1件だけ表示
sample = (
pois.reset_index()
.loc[lambda df: df["amenity"].eq("cafe")]
.dropna(subset=["name"])
)
poi = sample.iloc[0]
for key in ["element", "id", "name", "amenity", "shop", "geometry"]:
if key in poi.index:
print(f"{key}: {poi[key]}")
# element: node
# id: 839541210
# name: ルノアール
# amenity: cafe
# shop: nan
# geometry: POINT (139.5794323 35.7023946)
このように、普段のPythonの延長でPOIデータに触れられるのは大きな魅力です。FoursquareやOvertureについても、DuckDBやPythonから取得・分析できます。この記事の最後に、実際に動かしたコードと詳しい検証記事へのリンクをまとめておきます。
DuckDBは分析にかなり便利。ただし万能ではない
今回、FoursquareとOvertureの分析ではDuckDBを使いました。DuckDBはサーバーを立てなくてもローカルで動き、ParquetやGeoParquetを直接SQLで扱えるため、データ分析や検証用途では非常に使いやすいと感じています。特に「まずは手元で試したい」「重いデータをSQLでさっと見たい」という段階では、かなり強力です。
ただし、複数クライアントが同時にアクセスするWebサービスの中心データベースとしてそのまま使うのとは話が別です。そうした用途では、PostgreSQLやPostGISのような別の選択肢を検討した方がよいでしょう。POIデータを選ぶことと、それを保存・検索するデータベースを選ぶことは、分けて考えるのが自然です。
オープンデータはPOI活用の入口としてかなり便利
POIを使ったサービスや分析を考えたとき、最初から商用データを契約しなくても、プロトタイプや技術検証の段階なら、オープンデータでかなりのところまで試せます。今回のように、Foursquare、Overture、OpenStreetMapを使えば、取得方法の違い、カテゴリの考え方、住所や電話番号などの属性の入り方まで、かなり具体的に体験できます。
一方で、実際の業務で継続利用する段階になると、更新頻度、閉店情報、対象範囲、位置の確認、誰がどのように管理するか、といった別の要件が重要になります。私が業務で関わっているロケスマDATAは、国内のチェーン店舗を対象にしたデータベースで、公式情報を継続的に収集しながら更新しています。また、自動処理だけでは確認しにくい情報について、人による確認や調整も行っています。対象をチェーン店舗に絞っている点も、Foursquare・Overture・OpenStreetMapのような幅広いPOIデータとは性格が異なります。

図4 POI活用の流れ:オープンデータで試作し、必要に応じて運用・管理されたデータへ進む
ここで言いたいのは、オープンデータと商用データのどちらが上か、という話ではありません。まずオープンデータでPOI活用を試し、必要なデータや運用要件が見えてきた段階で次の選択肢を考える、という進め方はとても現実的です。
迷ったら、まず1つ触ってみよう
最初から3種類すべてを比較する必要はありません。SQLでPOIを分析したいならOverture、Placesとしてまとまった店舗・施設データを扱いたいならFoursquare、地図や道路・建物と一緒に使いたいならOpenStreetMap、と考えれば、最初の一歩はかなり選びやすくなります。どれか1つ触ってみるだけでも、POIデータがどのような構造になっているのか、何ができそうなのかはかなり具体的に見えてきます。
実際に試したコード・詳しい検証
今回紹介した3データについて、個人ブログでは実際の取得方法や検証結果まで詳しくまとめています。
- Foursquare Open Source Placesを使ってみる:DuckDBで日本のPOIを取得する
- Overture Maps Placesを使ってみる:DuckDBで日本のPOIを取得する
- OpenStreetMapを使ってみる:OSMnxで吉祥寺周辺のPOIを取得する
- Foursquare・Overture・OpenStreetMapを比較:POI件数・住所・電話・Webサイト
再現用コードはGitHubのgeoai-open-labで公開しています。この記事では全体像と選び方に絞りましたが、細かな取得条件、カテゴリ構造、ライセンス、実測条件まで確認したい場合は、上記の記事とリポジトリを参照してください。
※本記事では、筆者が業務で関わっているロケスマDATAについて一部言及していますが、内容は個人の見解に基づくものであり、所属企業の公式見解を示すものではありません。
