人口の少ない自治体の地図を作ろうプロジェクト

日本は災害の多い地域であり、災害の対応において、地図の存在は非常に大きなものです。
OpenStreetMapでは主にCrisis Mappingという形で、災害時における地図作成活動が行われています。

ただし、日本におけるその活動は、[今後も実施方法について検討が必要であるという認識](http://qiita.com/nyampire/items/24755286be57c42348ee)です。
また、先日の鳥取震災においては、遠隔から大量に行われた編集によって多くのデータが誤編集、あるいは破壊され、地元のマッパーが編集意欲を失ってしまうなどの事態を引き起こしています。

また、本家HOTの活動についても、災害発生時のマッピングがひとつの柱としてありつつ、基本は防災・減災の活動となっています。
日本においても、その流れでなにかできないかな、と考えていたのですが、とりあえずやってみよう、ということで、始めてみます。

プロジェクトの名前は "god is in the detail（神は細部に宿る）"です。
僕が管理している[HOT Tasking Manager](http://nyampire.info/)で実施しています。


# 日本における小規模自治体
日本には2014年時点で、[1718の市町村が存在](http://www.soumu.go.jp/gapei/gapei2.html)します。
そのうち、[人口10000人以下の自治体は536ほど存在](http://www.soumu.go.jp/menu_news/s-news/01gyosei02_03000062.html)します。
そうした自治体では、都市計画図の作成（公共測量）による高い位置精度（1/2500）をもった地図を保有できていないことがしばしばあり、また、定期的なデータの更新（本来は5年に1度）についても困難を有しているという課題があります。

ここをなんとかするのがよいのではないか、と考えました。

# Project "神は細部に宿る"
準備作業についてですが、まずはQGISを使って、[Mapzenが作成した世界各地の administrative boundaryデータ](https://mapzen.com/data/borders/)を分割しました。

[対象となるファイル](https://s3.amazonaws.com/osm-polygons.mapzen.com/japan_geojson.tgz)は、admin_leve=7、つまり市町村自治体（city, town, village）です。admin_level=8である、区（suburb）が丸められてしまいますが、区である時点で人口が多く、あとまわしになるはずの自治体です。気にしないで続けます。

![スクリーンショット 2016-12-13 7.45.50.png](https://qiita-image-store.s3.amazonaws.com/0/9928/52b35b2f-be97-2386-891c-bc695076578a.png "スクリーンショット 2016-12-13 7.45.50.png")


QGIS(2.14)のメニューでゆけば、`ベクタ→データマネジメントツール→ベクタレイヤの分割`から実施できます。

分割されたあとはそれぞれの自治体ごとにshapefile形式のファイルが出力されます。これらのファイルを、Tasking Managerの登録に必要な、geojson形式に変換し直す必要があります。

変換作業ではまず、ファイル名に空白があるので、[空白を除去します](http://stackoverflow.com/questions/2709458/bash-script-to-replace-spaces-in-file-names)。

でもって、できあがったファイルを、ogr2ogrを使って変換します。
[ここ](http://stackoverflow.com/questions/21512445/how-to-convert-country-level-geojson-using-qgis-using-data-from-naturalearthdata)が参考になりました。

最終的に使ったコマンドは以下のとおりです。（サンプルからの差分は、-loc引数がなくなっていること、-f引数でgeojsonファイルを指定したこと、の2点です）

```
for f in *.shp; do ogr2ogr -f GeoJSON `basename $f .shp`.json $f ; done
```

総務省が作成している資料（[住民基本台帳に基づく人口、人口動態及び世帯数](http://www.soumu.go.jp/menu_news/s-news/01gyosei02_03000062.html)）をもとに、人口の少ない自治体を割り出しました。
ここから、対象となる自治体を探して、Tasking Managerに追加します。

ほんとうはここで、Mapzenのデータに対して、自治体の人口の属性カラムを追加し、分割や追加をやりやすくするべきなのですが、QGISの操作に慣れておらず、作業をすることができていません。
どなたか、よい方法があれば教えてください m(_ _)m
（久々に、OSM側のカラムとして[全国地方公共団体コード](http://www.soumu.go.jp/denshijiti/code.html)が追加されているといいのになぁ、と思ってしまいました。そのうちやりたいです。ref:**** というタグ名称になると思われるので、****の部分を決めないといけません）

# [Tasking Manager](http://nyampire.info/)への追加
かーさんがよなべーをしてー。。。♪
ひとつひとつ、丹精を込めてTasking Managerに文章をコピペし、登録をします。

。。。結構面倒くさいですｗ

けど、ひとまず、小規模自治体を40個ほど、Tasking Managerに登録してみました。
いくつか手がけてみて、改善できる部分は改善してゆきたいと考えています。

プロジェクトのコピー機能とかあるといいのかもしれないですが、こういう使い方する人は多くないと思うので、リクエスト出すのも憚れてどうしたものかなー、という印象です。

![スクリーンショット 2016-12-13 7.52.20.png](https://qiita-image-store.s3.amazonaws.com/0/9928/2f9b752f-9269-3893-1910-10fae99f596d.png "スクリーンショット 2016-12-13 7.52.20.png")

* [nyampire.info - HOT Tasking Manager](http://nyampire.info/)

# どんなことをするのか
基本的に、地域の中に存在する **建物** を描画してゆきます。

ただ、以下のことに気をつける必要があります。
> 詳しくはプロジェクトの「インストラクション」部分にも記載しています。
> 後ほど、この部分は分割して、詳しい描き方のドキュメントを作成する予定です。

## 描画対象
主な描画対象は **「建物」** です。

また、建物を描いた時にポリゴンやウェイが交差したり重複したりしないよう、 **「建物の近くの道路」** も一緒に整備するとよいでしょう。
公民館の近くの駐車場などは、たいていどこの役場でもそれなりに広くスペースが確保されており、描きやすいです。

背景となる衛星写真はMapbox Satelliteを使うと、山間部などであってもカバー率が良好です。
もしMapbox Satelliteでも表示がされない場合は、[地理院地図（標準タイル](https://wiki.openstreetmap.org/wiki/JA:GSImaps)を使うのがよいと思います。

また、もし衛星写真のオフセットが変更できる環境で作業している場合、位置のあわせは、[地理院地図（オルソ）](https://wiki.openstreetmap.org/wiki/JA:GSImaps)にあわせるとよいと思います。
オフセットの調整方法については、[OSM wiki等](https://wiki.openstreetmap.org/wiki/JA:%E7%94%BB%E5%83%8F%E3%81%AE%E5%88%A9%E7%94%A8#.E3.82.A8.E3.83.87.E3.82.A3.E3.82.BF.E5.88.A5.E3.81.AE.E7.94.BB.E5.83.8F.E3.81.82.E3.82.8F.E3.81.9B.E6.96.B9.E6.B3.95)を参照してください。

## 描画しない対象
山奥などの **道路（特に一本道道路）の整備を深追いするのはやめましょう。**

明らかに航空写真とズレていても、今回のターゲットはそこではありません。（修正したくなる気持ちはとてもよくわかります :)）

さらにいえば、「正しい位置」へ補正を行うためには、位置の精度が高いGPSトラックが必要となります。そうしたGPSトラックが少ない現状では、精度の高い整備が不可能です。
航空写真だけを使って編集する場合、山奥の道路などで道路の位置をそもそも追いづらい、ということもあります。

また、データを実運用する観点からゆけば、山奥などで一本道の道路の場合にはその道路を使っていることが自明であり、分かれ道などで迷う可能性が比較的少ないだろう、ということもあります。
将来的に、GPSトラックなどを整備して再度チャレンジしたいと思っています。

それから当然ですが、「既にマッピングが精密に行われている地域」を無理に実施する必要はありません。
OpenStreetMapのマッピングにおいては、現地の活動が優先されるべきです。

## 描画しておくと将来幸せになりそうな対象
明らかな地図のエラーは、この機会に対応しておくとよいかもしれません。
特にJOSMを使って編集しているときには、「妥当性検証」を行っておくとよいでしょう。

また、修正しておいたほうがよいエラーの例の代表例として、 **森林ポリゴンと海岸線の交差** （海岸線の外側に、森林ポリゴンがはみ出ている状態）があります。

このエラーは、個人的に優先したい対象です。
これはもともと、Yahoo!Japanから提供された海岸線と、過去に国土数値情報からインポートした森林ポリゴンで位置に相違があることで発生しています。

![kaigan.png](https://qiita-image-store.s3.amazonaws.com/0/9928/98191396-6bf1-9c56-0676-8ca20e3a71b2.png "kaigan.png")


海岸線と森林は修正にやや手間がかかるデータです。
ただ、このエラーはもう何年も「よくある間違い」として指摘されている項目であり、この機会に少しでも減らすのはよいことだと思います。
（今後、MapRouletteなどを使って、別途でTaskにしてもよいかもしれないですね）

# 今回のプロジェクトにおけるメリット
このプロジェクト、地域の防災などで使えたらよいなあ、と思っているとともに、他にこんな効果もあるのかな？と思い始めています。

## 遠隔マッピングのサンプル地域として
アームチェアマッピングを行う際に、対象となる地域の選定はとても難しいです。
広すぎず、狭すぎず、多人数で実施しても競合が発生しないエリアというのは、考え始めるときりがありません。

そうした場合に、対象として描画をしてみるとよいのかな、と思っています。

また、実際の作業において、人口の少ない市町村というのは、もともとが人口密集地域が少ない地域ですから、描く対象もそれほど多くなく、1つのタスクが1時間ほどで作業が完了します。
実施した作業の確認（バリデーション）を含めても、メリハリをつけた作業時間を確保することができ、2−3時間程度の講習会でも扱いやすいサイズになっています。

## 商業地図との差別化について
日本では商用の地図、特にGoogle MapsやYahoo!地図、そしてそのもとになっているゼンリン社の活動が素晴らしく、都市部においては世界でも例を見ないほど高品質の地図が整備されています。

しかしながら、離島や山間部などの地域は、商業的にあまり大きなインパクトを有しておらず、地図の更新が滞りがちになってしまっています。
OpenStreetMapではこうした地域の地図を優先的に整備することによって、他の地図がカバーすることが難しい地域の手助けをすることができます。
商用地図とOSMを同じ土俵の上にのせて「どちらのほうが使える」と比較する不毛な議論ではなく、「お互いがお互いの特色を活かす」ほうが、社会が総体として、前進できると思うのです。

![スクリーンショット 2016-12-13 7.50.57.png](https://qiita-image-store.s3.amazonaws.com/0/9928/5a980524-5916-692e-e81b-a1339d8b76ba.png "スクリーンショット 2016-12-13 7.50.57.png")


# 今後の改善点について
## ファイル名に、市町村の人口を入れたい
Tasking Managerに登録する時にとても手間なので、やっぱり属性カラムに市町村の人口を付け足しておきたいと思っています。
ただ、OSMデータ側には市町村のコードが整備されておらず、QGISのなかでどういう操作をすれば作業ができるのか、いまいちよくわかっていません。

もしかしたら、人口で分割するのをやめて、最初は「町と村」を対象にしてしまうのがよいのかもしれません。
平成26年時点で、[町が745、村が183](http://www.soumu.go.jp/gapei/gapei2.html)ありますので、合計で約920個。
市になるためには人口が5万必要なので、少なくともそれ以下の自治体をカバーできることになります。

総数1712の半数も超えることができますので、よく言われる「OSMのカバー率」として、「自治体数で半分は描いてますよ」と返すことができるようになります。（カバー率っていう言葉自体が、相当バイアスのかかった変な聞き方の気がしますけどね）

## 海の部分を作業対象外にしたい
OSMの自治体ポリゴンは、海の上までごそっと広がった形状になっています。
Tasking Managerに登録された後に、それらの海上部分も、「作業対象地域」として登録されてしまっています。
これもQGISを使って、陸地部分だけを作業対象のポリゴンにしたいなぁ、と思っています。
もしかしたら、QGISではなくて、PostGSISを使うほうがよいのかもしれないですが、どうやったら望む結果が出せるのか、ちょっとよくわかっていません。

![kirinuki.png](https://qiita-image-store.s3.amazonaws.com/0/9928/bd6942a9-331a-8d5f-dd3a-04f04990735f.png "kirinuki.png")


## 名称が重複している自治体
Wikipediaのページ「[同一名称の市町村一覧](https://ja.wikipedia.org/wiki/%E5%90%8C%E4%B8%80%E5%90%8D%E7%A7%B0%E3%81%AE%E5%B8%82%E5%8C%BA%E7%94%BA%E6%9D%91%E4%B8%80%E8%A6%A7)」に詳しいですが、日本には名称が重複している自治体、というものが存在します。
現在の分割方法では、名前をもとに分割を行っているため、名前が重複している場合、2つの自治体が1つのファイルとして分割出力されます。
あまり格好が良いものではないので、これもなんとかしたいところです。

県や郡の名称、人口などを属性カラムにいれて、結合すればよいのですが。

## 対象自治体の一覧の作成
HackpadやOSM wiki、Google Docsなどで、作業完了したかどうかのチェックリストは作りたいなぁ、と思っています。
OSM wikiのほうがOSMプロジェクトとしては正しい気がするのですが、作成するのもチェックをつけるのも、ちょっと面倒くさいなぁ、と感じています。（ごめんね）

こういうのはうまいこと地図上に表示ができるとよいのですが、そういうのはGithubでページ作ればよいのかなぁ？（適当発言）

とまれ、このへんの作業について、「こうやればいいんじゃない？」というアイデアをお持ちの方はコメントいただけると嬉しいです。


# 先駆者
ちなみに僕がこのプロジェクトを思いつくきっかけになったのは、[奈良県 下北山村](http://www.openstreetmap.org/#map=17/34.03864/135.96387)（参考: [同地点の地理院地図](https://maps.gsi.go.jp/#17/34.038787/135.962870/&base=std&ls=std&disp=1&vs=c1j0l0u0f0
)）におけるマッピング活動でした。

みなさんもぜひ一度、みてみてください。
奈良県 下北山村では、現地マッパーによる非常に細かい情報が記載されており、すべての建物が描かれ、そして、amenity=shelterとして、防災拠点もマッピングされています。

![スクリーンショット 2016-12-13 8.04.56.png](https://qiita-image-store.s3.amazonaws.com/0/9928/4d7d6389-aa05-c525-5e0a-599827fd7481.png "スクリーンショット 2016-12-13 8.04.56.png")


OpenStreetMapは、三点測量を中心とした位置精度という観点からいえば、測量の基準は全く満たしていません。しかしながら、現地の活動が加わった"生きている"地図は、その地域で"生きている"人たちの役に立つことができるのだ、と感じられます。

こうした地域が増えることが、とても望ましいと思っています。

Tasking Managerを使ったこのプロジェクトは、いわゆるアームチェアマッピングの作業です。
アームチェアマッピングは、その品質や手法について、定期的に批判が起きる手法です。僕も、完璧だとは思っていません。
ただ、遠隔でできることの限界を見極めた上で、でも、遠隔からできることは遠隔から行い、地元では、本来やりたかったこと、やるべきことがすぐにスタートできるような状態にしておくことも、重要だと思っています。

みんなの手で、日本の地図の底力があがる、そんな活動にしてゆきたいな、と思っています。

Happy Mapping! :)