State of the Map Japan 2014にて発表させていただいた内容です。

1. 国土数値情報
行政区境データの
インポート報告
いいだ さとし
@nyampire
2014/12/13
State of the Map Japan 2014
Map data is ©OpenStreetMap Contributors and licensed ODbL
Map Image is OpenStreetMap.org licensed CC BY-SA 2.0

2. 自己紹介

3. 自己紹介
飯田 哲 (いいだ さとし)
Twitter @nyampire
An Addicted Mapper
OpenDataまわりの活動もちょっと
使用武器: ガンランス
(｀・ω・́) < 基本ソロです！

4. 自己紹介

5. 最近やってること

7. 最近やってること
(再掲)

8. 国土数値情報

10. 国土数値情報の
おさらいと振り返り

11. 国土数値情報ライセンス
第２条 利用上の注意
[snip]
(3) 国土情報およびそれを利用者が編集・加工して作成した成果物を他に転載、引用
等する場合は、利用者は「国土数値情報（○○データ） 国土交通省」「国土画像情
報（カラー空中写真） 国土交通省」のように出典を明記してください。ま
た、国土数値情報の整備年、国土画像情報の撮影年・撮影場所、ファイル名、編集・
加工した場合には編集・加工責任者等の情報についても、できる限り併記してくださ
い。

12. OSM wikiにて出典の明記
および利用データや方法を明確化
オブジェクトや変更セットへのsourceタグ表示
インポート専用アカウントの作成
およびOSM wikiでの解説ページと紐付け

13. 今回のインポート作業

14. KSJ2作業の歴史
•2008-2009年
国土数値情報データの利用開始 (全てのノードオブジェクトに情報付与)
利用データ: 海岸線、森林、公共施設、行政区域、空港、湖沼、発電所、鉄道、河川
•2012年
海岸線データをYahoo/ALPSデータに切り替え (by ikiya & TomG3X)
ODbLデータ切り替えにより、西日本を中心とした森林データ消失
sourceタグの付与を、全てのノード・オブジェクト対象ではなく、ウェイやリレーション対象へと切り替え
•2013年
消失した森林データの再インポート提案が、Imports MLにてReject (位置の不正確さのため)
admin_level、place、addr:* などのタグについて、分類の実施完了
•2014年
行政区域データのインポートを提案、実施準備
4月 Talk-ja MLにて提案
5月 Imports MLにて提案
6月末 2014年度版KSJ2行政区域データ公開
8月 行政区域データ再インポート開始

15. インポート作業内容

16. 事前調整
OSM wikiでのドキュメント作成 (2014年4月、5月、6月くらい) •作成した計画概要ドキュメント。日英両方が必要。
•http://wiki.openstreetmap.org/wiki/JA:Import/Catalogue/Japan_KSJ2_Import/
Administrative_district_2014 •インポートガイドライン
•http://wiki.openstreetmap.org/wiki/Import/Guidelines •計画概要のドキュメントテンプレ
•http://wiki.openstreetmap.org/wiki/Import/Plan_Outline
Talk-ja, Imports MLにて、ドキュメントを提示しつつ、主に以下4点を実施•データのライセンスについて解説•データの内容の解説•データ変換後サンプルの提示•作業計画と作業内容の提示

17. インポート用データの準備
インポート用の元データ作成 (2014年7月、8月くらい)
国土数値情報の元データのダウンロード (Shapefile形式)
ogr2osmスクリプトを使って、Shapefileを.osm形式に変換
.osmをひとつひとつ、JOSMで編集•リレーション化 (マルチポリゴン化) •name:en、name:ja_kana等のタグを追加•トポロジ化 (JOSMの“重複をマージ”機能が便利)
だいたい1ファイル3-4時間くらい？

18. データ投入手順
1. 既存データの整備
1. 既存の行政区境データをダウンロードして確認
1. 既存のplaceノードと、boundaryウェイデータをダウンロード
2. 既存リレーションデータをダウンロード(もしあれば)
3. 1と2のレイヤをマージ
2. 別レイヤとして、インポート用データを読み込み
3. インポート用データから1市町村ずつ、既存データと調整しながらアップロード
4. 全ての市町村がアップロードされているか、リストで確認
5. 全市町村のアップロードが完了したら、以下を適宜実施
1. データのトポロジチェック
2. 郡リレーション、政令指定都市リレーションを作成
3. 既存KSJ2データを削除
4. 県リレーションのメンバーを入れ替え
6. 県と県の間のウェイをトポロジ化
次ページから
ひとつずつ解説

19. データ投入手順
1. 既存の行政区境データをダウンロードして確認
1. 既存のplaceノード (role “label”用) と、boundaryウェイデータをダウンロード
2. 既存リレーションデータをダウンロード(もしあれば)
3. 1と2のレイヤをマージ

20. データ投入手順
1. 別レイヤとして、インポート用データを読み込み
2. インポート用レイヤから1市町村ずつ、既存データと調整しながらアップロード

21. データ投入手順
1. 全ての市町村がアップロードされているか、リストで確認
•Shapefileの.dbfファイルからCSV作成•hackpadでチェックボックス作成•特に、郡や政令指定都市（区）の所属チェック

22. データ投入手順
1. 全市町村のアップロードが完了したら、以下を適宜実施
1. データのトポロジチェック
2. 郡リレーション、政令指定都市リレーションを作成
3. 既存KSJ2データを削除
4. 県リレーションのメンバーを入れ替え
例えばここのウェイは
1つのウェイオブジェクトで
2つ以上の区画リレーションに所属する。
admin_levelタグはリレーション側で保持。
そのため、ウェイには付与せず。

23. データ投入手順
1. 県と県の間のウェイをトポロジ化
この部分

24. 進捗どうですか

25. KSJ2_adm_bnd_imprtアカウント編集履歴より

26. 01_Hokkaido.osm
02_Aomori.osm
03_Iwate.osm
04_Miyagi.osm
05_Akita.osm
06_Yamagata.osm
07_Fukushima.osm
08_Ibaragi.osm
09_Tochigi.osm
10_Gunma.osm
11_Saitama.osm
12_Chiba.osm
13_Tokyo.osm
14_Kanagawa.osm
15_Niigata.osm
16_Toyama.osm
17_Ishikawa.osm
18_Fukui.osm
19_Yamanashi.osm
20_Nagano.osm
21_Gifu.osm
22_Shizuoka.osm
23_Aichi.osm
24_Mie.osm
25_Shiga.osm
26_Kyoto.osm
27_Osaka.osm
28_Hyogo.osm
29_Nara.osm
30_Wakayama.osm
31_Tottori.osm
32_Shimane.osm
33_Okayama.osm
34_Hiroshima.osm
35_Yamaguchi.osm
36_Tokushima.osm
37_Kagawa.osm
38_Ehime.osm
39_Kouchi.osm
40_Fukuoka.osm
41_Saga.osm
42_Nagasaki.osm
43_Kumamoto.osm
44_Oita.osm
45_Miyazaki.osm
46_Kagoshima.osm
47_Okinawa.osm
ここらへんが
完了
変更セット数760強
だいたい 700/1718 市町村程度？

27. 最終的に目指すもの

28. 住所情報
address

29. 自由な
ジオコーディングが
したいです

30. 住所の入力方法
例として、JIPDEC (日本情報経済社会推進協会) の所在地
〒106-0032
東京都 港区 六本木一丁目 9番 9号 六本木ファーストビル内
addr:full = 東京都港区六本木一丁目9番9号 六本木ファーストビル内
addr:postcode = 106-0032
addr:province = 東京都
addr:city = 港区
addr:quarter = 六本木
addr:neighbourhood = 一丁目
addr:block_number = 9
addr:housenumber = 9
addr:flats = 六本木ファーストビル

31. 面倒！！

32. 対策！！

33. 行政区域リレーション構成
県→郡→市町村→大字(町名)→丁目→街区、の順番に、
member role “subarea”として、子リレーションを登録することで
addr:*タグの階層構造を明示化 (is_inタグは古い仕様で、強い意味は無いです。無くはないけど)
大阪府→三島郡三島郡→島本町

34. 住所の入力方法
例として、JIPDEC (日本情報経済社会推進協会) の所在地
〒106-0032
東京都 港区 六本木一丁目 9番 9号 六本木ファーストビル内
addr:full = 東京都港区六本木一丁目9番9号 六本木ファーストビル内
addr:postcode = 106-0032
addr:province = 東京都
addr:city = 港区
addr:quarter = 六本木
addr:neighbourhood = 一丁目
addr:block_number = 9
addr:housenumber = 9
addr:flats = 六本木ファーストビル
←KSJ2行政区域のエリアデータが構成されていれば、
ここを入力省略可能

35. 住所の入力方法
例として、JIPDEC (日本情報経済社会推進協会) の所在地
〒106-0032
東京都 港区 六本木一丁目 9番 9号 六本木ファーストビル内
addr:full = 東京都港区六本木一丁目9番9号 六本木ファーストビル内
addr:postcode = 106-0032
addr:province = 東京都
addr:city = 港区
addr:quarter = 六本木
addr:neighbourhood = 一丁目
addr:block_number = 9
addr:housenumber = 9
addr:flats = 六本木ファーストビル
←丁目のエリアデータが構成できれば
ここも省略可能 (位置参照情報/ISJ？)

36. 住所の入力方法
例として、JIPDEC (日本情報経済社会推進協会) の所在地
〒106-0032
東京都 港区 六本木一丁目 9番 9号 六本木ファーストビル内
addr:full = 東京都港区六本木一丁目9番9号 六本木ファーストビル内
addr:postcode = 106-0032
addr:province = 東京都
addr:city = 港区
addr:quarter = 六本木
addr:neighbourhood = 一丁目
addr:block_number = 9
addr:housenumber = 9
addr:flats = 六本木ファーストビル
住居表示住所のフロンテージデータがあれば
←ここも入力視野 (ただし、基本測量成果データ)
海外の住所インポートでは、addr:city以下の
タグをNodeに付与することが多いようです

37. Surveyによる調査困難
番 (街区番号、番、block number) の境界線と、
号 (住居番号、号、house number) の位置は、現地調査による入力が困難
住居表示住所制度が実施されている自治体では、各戸に標識がある。
地籍ベースの自治体では、標識の設置義務が無いため、著しく調査が困難。
→最終的には、地元の人に住所を聞いて回るしかない。。。
また、号は必ずしも順番に並んでいるわけではない。
→最初は、店舗等POIの住所から？
addr:block_number = 23
addr:housenumber = 19
from OSM wiki CC BY-SA2.0
http://wiki.openstreetmap.org/wiki/
File:Japanese_address_housenumber.png

38. ざっくりとした“号”の位置であれば
addr:interpolationによる
addr:housenumber補間

39. 行政区域データの使い途
OverPass APIを使って行政区域ごとのクエリがかけやすくなるため、
HOT Tasking Managerによる区域指定が楽に。•例えば、森林の描画を市町村単位で実施。•例えば、Yahoo Japan/ALPS道路データのチェック・ブラッシュアップ。•入力データValidation機能を使うことで、データ作成のチュートリアルも可。
テストインスタンス起動中です
プロジェクト作成テストは応相談
権限お渡しします
http://nyampire.info

40. 夜中に、県内の松屋の数を
調べたくなった時とか

41. 今後のインポート関連作業
•行政区域データインポート完了予定
あと半年くらい？京都府、愛知県、東京都、埼玉県、北海道あたりが難所か。
•過去のKSJ2データのブラッシュアップ、差分作業
主な対象: 河川、鉄道
チャレンジ: shapefileをgeojson変換してdiffとるとかできるかな？ geogig？
•KSJ2データをトレース用データ・タイルに変換
主な対象: バス経路、土地利用(？)
チャレンジ: 直接インポートではなく、参照用データとして利用できないかしら
•これからのインポート？
KSJ2: 小学校区、中学校区、自然公園地域(？)
ISJ: 位置参照情報の利用、丁目エリアとリレーション subarea の作成
その他: 衆議院の選挙区ポリゴンデータ
チャレンジ: 全国分となると、かなり大変な作業。どうしようかしら。

42. 例: 河川・鉄道のデータ改善
リレーション化など、既存の情報の改善はわりと簡単。
中級者向けチュートリアルに？

43. 目下の悩み

44. 海上の境界線
海上境界線についての扱い。海岸線と行政区域データ。
boundary = maritime?
or
boundary = administrative?
海上を走るのは
administrativeじゃなくて
maritimeじゃないかなぁ。。。

45. maritime
文章難しい ヽ(･ω･)/

46. 行政区データ is fragile
行政区域データは、意図しない編集でも非常によく壊れる。。。
特に初心者にとって、ぱっと見てなんのためにあるのかわからないデータ
しかも、壊れたことの検知がしづらい
→海外でもよく話題になり、行政区域データをOSM DB外で管理する案も
ただし、当面の対策は必要
WhoDidItによる変更セット監視？
→矩形範囲内でのチェック機能あり、でもやりたいのはオブジェクト監視
GeofabricのDaily DumpをPostGISに入れてトポロジチェックかな？
でもそもそも、Big Brotherしたくない。
相談させてヽ(･ω･)/

47. そして重めの

48. 県境未定地

49. 県境未定地
パターンは2つ
•自治体ごとに主張する境界線が異なる•そもそも本来的に、境界が存在しない (湖の上、山の中など)
でも、GISの仕様上、ポリゴンは閉じる必要がある
現在のところ、「仮の」対応策として、県境未定地のウェイを閉じて構成
将来的に、osm2pgsql、imposm等のコードを改良する必要性？
閉じたラインストリングをポリゴンに変換する機能 ST_MakePolygon を使っている？
(この機能は、入力ジオメトリが閉じている必要がある)
強制的にラインストリングを閉じる機能 ST_AddPoint の処理を入れるとか？
Nominatim用のDatabaseを作るosmosisの処理だと、ST_AddPoint 処理が入ってる？
同様の問題として、市町村境未定地、筆界未定地っていうものもあってな？

50. 問題がたくさん？

51. そのとおり
OPEN
だからこそ
問題をオープンに
議論をオープンに

52. 自由な地図を
次の段階へ

53. 私たちの手で！
ヽ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾒ(ﾟ∀ﾟ)ﾉ

54. つづく