All is FOSS4G (in GSI Maps)

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

地理院地図　http://maps.gsi.go.jp/ 2 電子地形図を含む、ウェブ向け地図データ「地理院タイル」を提供。その利用のショーケースとして国土地理院のウェブ地図として運営。国土地理院が捉える日本の姿を、ウェブを通じて日本や世界に提供。地形図写真地形分類災害情報

Slide 3

Slide 3 text

３つの施策と３つの技術 3 地理院タイルの活用を推進するための３つの施策 ①オープンデータ施策政府戦略に基づき使いやすく提供する ②オープンソース施策オープンソースを利用し、提供する ③オープンイノベーション施策　　　産学官連携を積極活用し、イノベーティブな成果を追求する地理院地図の今後を方向付ける3つの技術 ①標高タイル標高・地形が当たり前に分かるように ②ベクトルタイル多様な表現と情報処理を可能に ③デジタルファブリケーション　新しいものづくりの技術を活用し、ニーズに合わせてものをつくる

Slide 4

Slide 4 text

4 SHARE

Slide 5

Slide 5 text

2つの経験を共有したい •  オープンソース＋オープンデータ→オープンイノベーション –  10月1日〜2日　GitHub Universe –  「Changing Lives with Open Data」セッションでの発表 •  ベクトルタイル –  10月8日　FOSS4G 2015 Tokyo ハンズオン –  「ベクトルタイル利用サイトを作ろう」の講師 5

Slide 6

Slide 6 text

GitHub Universe の経験 1200万人オーダーのユーザ数 1200人オーダーの参加者（オンラインを含め延べ15000人） 2700万件オーダーのプロジェクト 44件の発表実課題分野の担当者をそのままソフトウェア開発者にする。 6

Slide 7

Slide 7 text

COLLABORATE BREAKOUT（分科会） Changing Lives with Open Data 　・地理院地図を用いた災害情報の迅速提供　・GTFSデータ等を利用した交通網設計ツール　・ロサンゼルス市のオープンデータ活用の改善 7

Slide 8

Slide 8 text

https://speakerdeck.com/hfu/ ※プレゼン内容についてはオンラインで確認頂けます。 8

Slide 9

Slide 9 text

課題の近くでコードせよ「実課題分野の担当者をそのままソフトウェア開発者にする。」という流れあるいは「課題の近くでコードせよ」という流れ →我々地理空間情報技術者、特に FOSS4G ユーザは、その流れの真ん中にいる。 9 自信を持って進もう！

Slide 10

Slide 10 text

ベクトルタイル利用サイトを作ろう地理院地図の実運用で使っている方法をそのままシェア 10 10月8日　14：00〜17:00　FOSS4G 2015 Tokyo ハンズオンデー

Slide 11

Slide 11 text

地理院地図のフォーク地理院地図の分身を作ってもらい、それぞれの課題に必要なデータを加えてもらう。すべてウェブ上で実現できる。 11

Slide 12

Slide 12 text

ソフトウェアの fork, pull request and merge 12 fork 成功例：被災前後比較サイトでの IE9以降対応 pull request merge ソフトウェアの分身を作る分身の側で進めた改善を分身元でも反映することを求める分身元の方で、求められた反映を実施する

Slide 13

Slide 13 text

ウェブ地図の fork and join 13 地理院地図を分身分身間でレイヤを共有主体間の分散非同期を確保し、ユーザの利便を最大化できないか。

Slide 14

Slide 14 text

14 地理院地図のすべてが FOSS4Gになる

Slide 15

Slide 15 text

オープンソースのメリットの拡大 •  オープンソース、オープンデータのメリットの顕在化を進めてきた。 •  さらにオープンソース化を進行し、より可用性高く、ユーザにとって価値の高い地理院地図を提供して、オープンイノベーションを進める。「地理院地図のすべてがFOSS4Gになる」 15

Slide 16

Slide 16 text

すべてが FOSS4G になるこの先半年の開発の方向性【サーバサイドをコンテナに入れてオープン化】 •  サーバサイド処理もオープンソースを条件にして組み直し、GitHub から Dockerfile 配布する【地理院地図のスケーラビリティを強化】 •  膨大なレイヤ数に対応できるようJSを工夫 •  サーバサイド処理の削減を進行する 16

Slide 17

Slide 17 text

内部APIのコンテナ技術対応調達の都合上、地理院は年度毎にサーバを渡り歩ける必要がある。より渡り歩きやすくしつつ共有もできるよう、コンテナ技術に載せる。 17 地名検索リバースジオコーダ標高API カウンタ

Slide 18

Slide 18 text

内部APIのコンテナ技術対応地理院地図に付随的な、小さな内部API。だからこそ、ポータビリティ高く Docker の上で動くようにする。 •  年内に開発を終える •  開発の成果物は、GitHub に置く •  ソフトウェアのライセンスはCC0を予定する •  開発するサービスは、HTTPS対応にする →　地理院地図サーバのポータビリティ向上 →　動的機能の分散化余地の拡大 18 地名検索リバースジオコーダ標高API カウンタ

Slide 19

Slide 19 text

オブジェクトストレージ対応（やや内部的） •  地理院タイルのオリジンサーバを、従前の Linux 仮想マシンからオブジェクトストレージに変更する。 •  国土地理院が実施していたオリジンサーバのシステム管理が不要になり、可用性強化。 19 オリジンサーバ CDN ユーザ

Slide 20

Slide 20 text

HTTPS配信対応!! （4月からタイル配信に導入） •  ユーザ・CDNキャッシュ間の通信に、HTTPだけではなく HTTPS を使えるようにする。 – 世の中の動向に追従。ついに HTTPS サイトからも地理院タイルを安心してご利用可能に。 •  一方、HTTP/2 は今年は断念し、ドメインシャーディングを継続 – ドメインシャーディングは、従前通り試験公開扱いとして地理院地図自らは積極的に利用 20 オリジンサーバ CDN ユーザ

Slide 21

Slide 21 text

タイルアップロードマネージャの開発 •  地図の迅速更新の反映等のため、地理院からオリジンサーバへは実効で毎週数万〜100万タイルをアップロード –  1分間で100タイル書き換わるイメージ •  オブジェクトストレージの特性・性能を活用できるよう、アップロードの工夫もアップデート。 –  工夫の仕方もよりオープンな形で 21 オリジンサーバ CDN ユーザタイルのアップ

Slide 22

Slide 22 text

タイルアップロードマネージャオブジェクトストレージの特性に合わせ、 – 管理された並列アップロードにより高速化 – 「地理院タイル目録」の管理・生成も行い、自らのアップロードの効率化にも役立てる •  年内に開発を終える •  開発の成果物は、GitHub に置く •  ソフトウェアのライセンスはCC0を予定する 22 タイルオブジェクトストレージ

Slide 23

Slide 23 text

地理院地図（gsimaps）の改良「ソフトウェアの変化はデータの変化の10倍速い」　　　　　　　↓ ソフトウェアは積極的に改善しつつ、データの長期的安定性を追求していく。「データは単調増加する」　　　　　　　↓ データ増加にスケーラブルになる改良を優先する。 23

Slide 24

Slide 24 text

gsimaps 改良項目オーバービュー ①  layers.txt 動的読み込み ②  複数のココタイルへの対応 ③  ユーザインタフェース改良 ④  GeoJSON ドラッグ＆ドロップ ⑤  全状態のURLフラグメントへのリアルタイム反映 ⑥  「名前を付けて保存」の地理院地図との非連動化 ⑦  標高表示のクライアントサイド処理化 ⑧  3Dのクライアントサイド処理化 ⑨  PNG標高タイルの利用 ⑩  Microsoft Edge (Windows 10) 対応＜以下、リソース未割当（基本、来年度送り）＞ • layers.txtと「地理院タイル一覧」の統合 • ユーザインタフェース多言語化準備 • Leaflet 1.0 対応 24 今年度中対応予定

Slide 25

Slide 25 text

①layers.txt 動的読み込み地理院地図のレイヤ数は1,200を超えた ← 干渉SAR情報の充実 hfu$ ruby sl.rb | wc -l 1281 レイヤのメタ情報を、地理院地図の起動時にすべて読み込むのではなく、各レイヤグループを開く際に読み込めるようにする。　　　　↓ 地理院地図の起動を高速化 25 LayerGroup#src として仕様を作成済み

Slide 26

Slide 26 text

②複数のココタイルへの対応ココタイル：その位置にあるタイルのIDを集めたメタデータタイル地理院地図の「表示範囲に絞り込み」で使用 26 レイヤ数の増大に対応するため、ココタイルの管理を分散 →　地理院地図が複数のココタイルを扱えるように改造局所整備されたデータへの対応を強化

Slide 27

Slide 27 text

③ユーザインタフェース改良より少ないクリック数で直感的に操作いただけるよう、ユーザインタフェースを改善 27 操作ストレスの低減

Slide 28

Slide 28 text

④GeoJSON ドラッグ＆ドロップデスクトップからのドラッグ＆ドロップで GeoJSONファイルが地理院地図に載るように 28 実務での役立ち度向上

Slide 29

Slide 29 text

⑤全状態のURLフラグメントへのリアルタイム反映地理院地図の「リンクを取得」機能の課題　・　使うために呼び出す必要　・　チェックボックスを注意深く確認する必要　・　リアルタイムには反映しない問題　　↓ 地理院地図の状態をすべてリアルタイムに、クエリ（?...)でなくフラグメント（#...）に反映するようにし、わざわざ「リンクを取得」しなくても、「アドレスバーからURLをコピー」すれば良い形にする。　　↓ 29 ブラウザのSNS共有機能等との親和性向上

Slide 30

Slide 30 text

⑥「名前を付けて一時保存」の地理院地図との非連動化「名前を付けて一時保存」は、長期確保すべきデータを、移ろいゆくソフトウェアにロックインして保存すること。他方、1ファイルで保存できる手軽さがあることは理解。現状、保存時点の地理院地図を再現するため、すべての layers.txtのコピーを取るなどしており、保存ファイルの大きさは1.3MBを超える大きさになっている。「一時保存」するHTMLファイルの地理院地図との非連動化を進め、起動時に依存するリソースの削減や、保存 HTMLファイルのサイズ削減を目指す。 30 データやスクリーンショットの形で保存する方が、技術的に望ましい。

Slide 31

Slide 31 text

⑦標高表示のクライアントサイド処理化「標高タイルから指定位置の標高を取り出す」処理を、サーバ側（標高API）からクライアント側（JavaScript）に移動 31 地理院地図サービスのスケーラビリティ確保標高表示の高速化

Slide 32

Slide 32 text

⑧3Dのクライアントサイド処理化「地理院地図3D」の地理院地図との統合を進め、画面遷移を減らす等インタフェースを改善するとともに標高タイルからSTLデータ等を作成する部分について、サーバサイド処理をクライアントサイド処理に変更する。 32 サービスのスケーラビリティ確保火山災害が起こっても、自信を持ってご案内できる地理院地図3Dを目指す。

Slide 33

Slide 33 text

⑨PNG標高タイルの利用産総研シームレス地質情報研究グループが提案する「PNG標高タイル」を地理院からも提供実験 33 地理院地図の標高表示の高速化 Cesiumでの地理院標高タイル利用の高速化 quantized-mesh 形式との比較検討

Slide 34

Slide 34 text

⑩Microsoft Edge (Windows 10) 対応「地理院地図は多くの環境で動く」の早期確保 34 https://ja.wikipedia.org/wiki/Microsoft_Edge

Slide 35

Slide 35 text

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 •  地理空間情報の当事者こそが、自分たちでソフトウェアを作っていくべき。 •  オープンソースソフトウェアをソーシャルコーディングする形で、より簡単にコラボしよう。