More than 3 years have passed since last update.

「神社の位置データを共有する」GeoJSON&GitHub&OSM３分クッキング

Last updated at 2019-12-02Posted at 2016-01-04

（この記事は FOSS4G Advent Calendar 2015 の投稿記事です。）

遅ベントカレンダーということで、年が明けて三が日にこれを書いていますが、せっかくなので今年の豊富とTIPSをメモしたいと思います。

2016年は、SHPファイルからGeoJSONへの世代交代の年！

というわけで、今から10年前に世の中に登場したKMLデータ形式が地理空間情報の世界を塗り替えても、すべてをKMLに置き換えられない理由がいくつかありました。その一番の理由がそれまでのデファクトスタンダードだったSHP(シェープファイル)形式の存在です。

Googleトレンドで、全世界の検索ボリュームの中でのKML、SHPデータの相対ボリュームを比較すると、2007年にはKMLがSHPとの立ち位置を逆転していますが、その差は大きく離れるわけではないこともまた読み取れます。

一方で、じわじわとその足元から存在感を示してきているのが GeoJSON形式です。
ひとことで言うと、KMLで実現できなかったSHPファイルの世代交代は、このGeoJSONが近い将来成し遂げると思います。

その理由を述べます。

データ構造がシンプル、理解しやすい。
データと表現が分離されている（HTMLとCSSのような関係）
SHPが扱える点・線・面のベクタ型フィーチャのみにデータ型が限定されている。
文字化けトラブルが起きにくい。文字コードが UTF-8 に限定されている。
属性データの格納の自由度が高い。SHPのようにフィールド名制限とかほぼない。
デフォルトの座標系/測地系が EPSG:4326（緯度経度座標系/WGS84測地系）。
ヘッダーにcrsプロパティを記述することで任意の座標系/測地系に指定可能。
トポロジ構造化した TopoJSON 形式も用意されている。
JSON構造がベースなのでJavaScriptなどウェブマップサービスで扱いやすい。
QGISを始め多くのFOSS4Gツールでは既に読み込み/書き込みに対応している。
なによりGitHubで簡単に可視化できる。

というわけで、

ここでは、どれだけGeoJSONが扱いやすくなったのか、OSMとGitHubを使って実演してみます。

#新年なので、神社のPOIデータをOSMから引っ張り出す

##神社タグは religion=shinto
OpenStreetMap（以下OSM）には神社仏閣の位置データが多数格納されていますが、日本の神道の教会でもある神社はOSM上ではお祈りする場所として amenity=place_of_worship ( 稲荷神社のような道端の小さな神社はhistoric=wayside shrineとして定義) 、宗教として神道を意味する religion=shinto とタグを記述します。

2016年1月3日現在、世界で神社として登録されているPOIデータは約5,000箇所以上になるようです。

##神社タグからOverpass-Turbo APIで検索

この神社タグ religion=shinto を使って、 overpass-turbo API で検索してみます。検索用のスクリプトは以下の内容ですが、TagInfo のボタンをクリックすると簡単にスクリプトが生成されます。

/*
This has been generated by the overpass-turbo wizard.
The original search was:
“"religion"="shinto" global”
*/
[out:json][timeout:2500];
// gather results
(
  // query part for: “religion=shinto”
  node["religion"="shinto"];
);
// print results
out body;
>;
out skel qt;

ここでは横着して、既に用意したスクリプトをお使いください。 http://overpass-turbo.eu/s/dx2