All is FOSS4G (in GSI Maps)

FOSS4G 2015 Tokyo Keynote

Transcript

1. Ministry of Land, Infrastructure, Transport and Tourism Geospatial Information Authority of Japan All is FOSS4G in GSI Maps 〜地理院地図のすべてがFOSS4Gになる〜 Hidenori FUJIMURA Geospatial Information Authority of Japan 1 2015-10-12 FOSS4G Tokyo @Komaba RC, U-Tokyo Slides available at speakerdeck.com/hfu
2. 地理院地図　http://maps.gsi.go.jp/ 2 電子地形図を含む、ウェブ向け地図データ「地理院タイル」を提供。 その利用のショーケースとして国土地理院のウェブ地図として運営。 国土地理院が捉える日本の姿を、ウェブを通じて日本や世界に提供。 地形図 写真 地形分類 災害情報
3. ３つの施策と３つの技術 3 地理院タイルの活用を推進するための３つの施策 ①オープンデータ施策 政府戦略に基づき使いやすく提供する ②オープンソース施策 オープンソースを利用し、提供する ③オープンイノベーション施策 　　　産学官連携を積極活用し、イノベーティブな成果を追求する 地理院地図の今後を方向付ける3つの技術 ①標高タイル 標高・地形が当たり前に分かるように ②ベクトルタイル 多様な表現と情報処理を可能に ③デジタルファブリケーション 　新しいものづくりの技術を活用し、ニーズに合わせてものをつくる
4. 4 SHARE
5. 2つの経験を共有したい •  オープンソース＋オープンデータ→オープンイノベーション –  10月1日〜2日　GitHub Universe –  「Changing Lives with Open Data」セッションでの発表 •  ベクトルタイル –  10月8日　FOSS4G 2015 Tokyo ハンズオン –  「ベクトルタイル利用サイトを作ろう」の講師 5
6. GitHub Universe の経験 1200万人オーダーのユーザ数 1200人オーダーの参加者 （オンラインを含め延べ15000人） 2700万件オーダーのプロジェクト 44件の発表 実課題分野の担当者をそのまま ソフトウェア開発者にする。 6
7. COLLABORATE BREAKOUT（分科会） Changing Lives with Open Data 　・地理院地図を用いた災害情報の迅速提供 　・GTFSデータ等を利用した交通網設計ツール 　・ロサンゼルス市のオープンデータ活用の改善 7
8. https://speakerdeck.com/hfu/ ※プレゼン内容についてはオンラインで確認頂けます。 8
9. 課題の近くでコードせよ 「実課題分野の担当者をそのままソフトウェア開発者 にする。」という流れ あるいは「課題の近くでコードせよ」という流れ →我々 地理空間情報技術者、特に FOSS4G ユーザは、その流れの真ん中にいる。 9 自信を持って進もう！
10. ベクトルタイル利用サイトを作ろう 地理院地図の実運用で使っている方法をそのままシェア 10 10月8日　14：00〜17:00　FOSS4G 2015 Tokyo ハンズオンデー
11. 地理院地図のフォーク 地理院地図の分身を作ってもらい、それぞれの課題に必要な データを加えてもらう。すべてウェブ上で実現できる。 11
12. ソフトウェアの fork, pull request and merge 12 fork 成功例： 被災前後比較サイトでの IE9以降対応 pull request merge ソフトウェアの分身を作る 分身の側で進めた改善を 分身元でも反映することを 求める 分身元の方で、 求められた反映を 実施する
13. ウェブ地図の fork and join 13 地理院地図を分身 分身間でレイヤを共有 主体間の分散非同期を確保し、ユーザの利便を最大化できないか。
14. 14 地理院地図の すべてが FOSS4Gになる
15. オープンソースのメリットの拡大 •  オープンソース、オープンデータのメリットの 顕在化を進めてきた。 •  さらにオープンソース化を進行し、より可用性 高く、ユーザにとって価値の高い地理院地図 を提供して、オープンイノベーションを進める。 「地理院地図のすべてがFOSS4Gになる」 15
16. すべてが FOSS4G になる この先半年の開発の方向性 【サーバサイドをコンテナに入れてオープン化】 •  サーバサイド処理もオープンソースを条件にして 組み直し、GitHub から Dockerfile 配布する 【地理院地図のスケーラビリティを強化】 •  膨大なレイヤ数に対応できるようJSを工夫 •  サーバサイド処理の削減を進行する 16
17. 内部APIのコンテナ技術対応 調達の都合上、地理院は年度毎にサーバを渡り歩ける必要がある。 より渡り歩きやすくしつつ共有もできるよう、コンテナ技術に載せる。 17 地名検索 リバース ジオコーダ 標高API カウンタ
18. 内部APIのコンテナ技術対応 地理院地図に付随的な、小さな内部API。だからこそ、 ポータビリティ高く Docker の上で動くようにする。 •  年内に開発を終える •  開発の成果物は、GitHub に置く •  ソフトウェアのライセンスはCC0を予定する •  開発するサービスは、HTTPS対応にする →　地理院地図サーバのポータビリティ向上 →　動的機能の分散化余地の拡大 18 地名検索 リバースジオコーダ 標高API カウンタ
19. オブジェクトストレージ対応（やや内部的） •  地理院タイルのオリジンサーバを、従前の Linux 仮想マシンからオブジェクトストレージ に変更する。 •  国土地理院が実施していたオリジンサーバの システム管理が不要になり、可用性強化。 19 オリジン サーバ CDN ユーザ
20. HTTPS配信対応!! （4月からタイル配信に導入） •  ユーザ・CDNキャッシュ間の通信に、HTTPだ けではなく HTTPS を使えるようにする。 – 世の中の動向に追従。ついに HTTPS サイトか らも地理院タイルを安心してご利用可能に。 •  一方、HTTP/2 は今年は断念し、ドメイン シャーディングを継続 – ドメインシャーディングは、従前通り試験公開扱い として地理院地図自らは積極的に利用 20 オリジン サーバ CDN ユーザ
21. タイルアップロードマネージャの開発 •  地図の迅速更新の反映等のため、地理院からオリ ジンサーバへは実効で毎週数万〜100万タイルを アップロード –  1分間で100タイル書き換わるイメージ •  オブジェクトストレージの特性・性能を活用できるよ う、アップロードの工夫もアップデート。 –  工夫の仕方もよりオープンな形で 21 オリジン サーバ CDN ユーザ タイルのアップ
22. タイルアップロードマネージャ オブジェクトストレージの特性に合わせ、 – 管理された並列アップロードにより高速化 – 「地理院タイル目録」の管理・生成も行い、自らの アップロードの効率化にも役立てる •  年内に開発を終える •  開発の成果物は、GitHub に置く •  ソフトウェアのライセンスはCC0を予定する 22 タイル オブジェクト ストレージ
23. 地理院地図（gsimaps）の改良 「ソフトウェアの変化は データの変化の10倍速い」 　　　　　　　↓ ソフトウェアは積極的に改 善しつつ、データの長期的 安定性を追求していく。 「データは単調増加する」 　　　　　　　↓ データ増加にスケーラブル になる改良を優先する。 23
24. gsimaps 改良項目オーバービュー ①  layers.txt 動的読み込み ②  複数のココタイルへの対応 ③  ユーザインタフェース改良 ④  GeoJSON ドラッグ＆ドロップ ⑤  全状態のURLフラグメントへのリアルタイム反映 ⑥  「名前を付けて保存」の地理院地図との非連動化 ⑦  標高表示のクライアントサイド処理化 ⑧  3Dのクライアントサイド処理化 ⑨  PNG標高タイルの利用 ⑩  Microsoft Edge (Windows 10) 対応 ＜以下、リソース未割当（基本、来年度送り）＞ • layers.txtと「地理院タイル一覧」の統合 • ユーザインタフェース多言語化準備 • Leaflet 1.0 対応 24 今 年 度 中 対 応 予 定
25. ①layers.txt 動的読み込み 地理院地図のレイヤ数は1,200を超えた ← 干渉SAR情報の充実 hfu$ ruby sl.rb | wc -l 1281 レイヤのメタ情報を、地理院地図の起動時にすべて読み込むので はなく、各レイヤグループを開く際に読み込めるようにする。 　　　　↓ 地理院地図の起動を高速化 25 LayerGroup#src として仕様を作成済み
26. ②複数のココタイルへの対応 ココタイル：その位置にあるタイルのIDを集めたメタデータタイル 地理院地図の「表示範囲に絞り込み」で使用 26 レイヤ数の増大に対応するため、ココタイルの管理を分散 →　地理院地図が複数のココタイルを扱えるように改造 局所整備されたデータへの 対応を強化
27. ③ユーザインタフェース改良 より少ないクリック数で直感的に操作いただけ るよう、ユーザインタフェースを改善 27 操作ストレスの低減
28. ④GeoJSON ドラッグ＆ドロップ デスクトップからのドラッグ＆ドロップで GeoJSONファイルが地理院地図に載るように 28 実務での役立ち度向上
29. ⑤全状態のURLフラグメントへのリアルタイム反映 地理院地図の「リンクを取得」機能の課題 　・　使うために呼び出す必要 　・　チェックボックスを注意深く確認する必要 　・　リアルタイムには反映しない問題 　　↓ 地理院地図の状態をすべてリアルタイムに、 クエリ（?...)でなくフラグメント（#...）に反映するようにし、 わざわざ「リンクを取得」しなくても、 「アドレスバーからURLをコピー」すれば良い形にする。 　　↓ 29 ブラウザのSNS共有機能等 との親和性向上
30. ⑥「名前を付けて一時保存」の地理院地図との非連動化 「名前を付けて一時保存」は、長期確保すべきデータを、 移ろいゆくソフトウェアにロックインして保存すること。 他方、1ファイルで保存できる手軽さがあることは理解。 現状、保存時点の地理院地図を再現するため、すべての layers.txtのコピーを取るなどしており、保存ファイルの大 きさは1.3MBを超える大きさになっている。 「一時保存」するHTMLファイルの地理院地図との非連動 化を進め、起動時に依存するリソースの削減や、保存 HTMLファイルのサイズ削減を目指す。 30 データやスクリーンショットの形で保存する方が、技術的に望ましい。
31. ⑦標高表示のクライアントサイド処理化 「標高タイルから指定位置の標高を取り出す」処理を、 サーバ側（標高API）からクライアント側（JavaScript）に移動 31 地理院地図サービスの スケーラビリティ確保 標高表示の高速化
32. ⑧3Dのクライアントサイド処理化 「地理院地図3D」の地理院地図との統合を進め、 画面遷移を減らす等インタフェースを改善するとともに 標高タイルからSTLデータ等を作成する部分について、 サーバサイド処理をクライアントサイド処理に変更する。 32 サービスのスケーラビリティ 確保 火山災害が起こっても、 自信を持ってご案内できる 地理院地図3Dを目指す。
33. ⑨PNG標高タイルの利用 産総研シームレス地質情報研究グループが提案 する「PNG標高タイル」を地理院からも提供実験 33 地理院地図の 標高表示の高速化 Cesiumでの地理院 標高タイル利用の高速化 quantized-mesh 形式との 比較検討
34. ⑩Microsoft Edge (Windows 10) 対応 「地理院地図は多くの環境で動く」の早期確保 34 https://ja.wikipedia.org/wiki/Microsoft_Edge
35. Conclusion •  People who are really serious about geospatial information should make their own software. •  And people can more easily collaborate by social-coding open source software. 35 •  地理空間情報の当事者こそが、自分たちで ソフトウェアを作っていくべき。 •  オープンソースソフトウェアをソーシャルコー ディングする形で、より簡単にコラボしよう。