WEBVTT

1
00:00:00.000 --> 00:00:05.000
今日は、ひとつの問いから始めたいと思います。もし、地図そのものがWebになったら？

1
00:00:05.000 --> 00:00:10.000
私はこの問いを、もう30年以上考え続けてきました。

1
00:00:10.000 --> 00:00:14.000
なぜ、私はこの問いを考え始めたのか。なぜ、これほど長い間、この問いに取り組み続けてきたのか。

1
00:00:14.000 --> 00:00:20.000
そして、もっと重要なのは、なぜ今、もう一度この問いを考える必要があるのか。

1
00:00:20.000 --> 00:00:23.000
今日は、その物語をお話ししたいと思います。

1
00:00:24.000 --> 00:00:28.000
まず、簡単に自己紹介をさせてください。私は高木 悟といいます。

1
00:00:28.000 --> 00:00:32.000
私はキャリアの多くを、通信事業者であるKDDIで、

1
00:00:32.000 --> 00:00:38.000
技術の研究開発、そして実際のシステム構築に携わってきました。

1
00:00:38.000 --> 00:00:43.000
1990年代初頭、私は水中ロボットの技術や、

1
00:00:43.000 --> 00:00:49.000
海底ケーブルの敷設・保守に関わる仕事からキャリアを始めました。

1
00:00:49.000 --> 00:00:54.000
ちょうどその頃、World Wide Webが急速に広まりつつありました。

1
00:00:54.000 --> 00:01:00.000
私は、「この新しい技術を、こうした分野に使えないだろうか」と考えるようになりました。

1
00:01:00.000 --> 00:01:04.000
それがきっかけで、私はWeb技術の世界に入り、やがてWeb GISへとたどり着きました。

1
00:01:04.000 --> 00:01:14.000
それ以来、私は実際のシステムの構築と運用、そしてW3Cを通じたWeb標準化の両方に取り組んできました。

1
00:01:14.000 --> 00:01:18.000
そして、1995年にHyper-Layeringというアイデアを思いついてから、

1
00:01:18.000 --> 00:01:22.000
この30年間、実装と標準化の両面から、Webと地図の関係を探求し続けてきました。

1
00:01:22.000 --> 00:01:25.000
探求し続けてきました。

1
00:01:25.000 --> 00:01:32.000
1995年、阪神・淡路大震災が起きました。

1
00:01:32.000 --> 00:01:37.000
当時、私はWWWという新しい技術に強く惹かれていました。

1
00:01:37.000 --> 00:01:49.000
そして、この大災害をきっかけに、研究会で、災害時にさまざまな組織の情報をどうつなぐかという議論が起きました。

1
00:01:49.000 --> 00:01:57.000
そこで私は、これからのWebには、さまざまな組織が、それぞれ異なる情報を公開し、

1
00:01:57.000 --> 00:02:00.000
それらがハイパーリンクによってつながっていく世界になると考えました。

1
00:02:00.000 --> 00:02:08.000
そして、地図も同じようにできるのではないか、と考えました。一つの組織がすべてを管理する地図ではなく、

1
00:02:08.000 --> 00:02:17.000
異なる組織がそれぞれの情報を提供し、ユーザーが地図の上で自由に重ね合わせる。

1
00:02:17.000 --> 00:02:21.000
それが、私が考えたHyper-Layeringでした。

1
00:02:21.000 --> 00:02:29.000
当時の私にとって、Webとは、すべてを一つに集めるものではなく、独立した情報をつないでいくものでした。

1
00:02:30.000 --> 00:02:36.000
しかし、Webは別の方向へ進んでいきました。2000年代になると、Web 2.0、マッシュアップ、

1
00:02:36.000 --> 00:02:40.000
そしてやがてクラウドコンピューティングが主流になっていきました。

1
00:02:40.000 --> 00:02:49.000
これは、とても強力なモデルでした。しかし、その過程で、ひとつ大きな変化が起こりました。情報を統合する場所が、エッジからサーバーへ移ったのです。

1
00:02:49.000 --> 00:02:58.000
サーバーがデータを集め、サーバーが処理する。さらにサーバーが統合までする。そして、その結果をユーザーに届ける。

1
00:02:58.000 --> 00:03:05.000
これは確かに、とても便利でした。しかし同時に、新しい問題も生み出しました。ゲートキーパー、ベンダーロックイン、

1
00:03:05.000 --> 00:03:11.000
そして、少数の巨大なプラットフォームへのWebの集中です。

1
00:03:11.000 --> 00:03:18.000
これは、もはや単なる技術上の問題ではありません。デジタル時代そのものが抱える、構造的な課題になっています。

1
00:03:18.000 --> 00:03:27.000
そして、もうひとつ大きな出来事が起こりました。OpenStreetMapです。OSMは、素晴らしいオープンデータを作っただけではありません。

1
00:03:27.000 --> 00:03:34.000
地図そのものをオープンにしたのです。ひとつの組織が、「これが世界の地図です」と決めるのではなく、

1
00:03:34.000 --> 00:03:41.000
世界中の人々が地図を作り、共有し、利用できるようになった。これは、とても大きな変化でした。

1
00:03:41.000 --> 00:03:44.000
地図そのものが、みんなで作っていけるものになったのです。

1
00:03:44.000 --> 00:03:50.000
そしてこれは、私が1995年にWebについて考えていたことと、深くつながっています。

1
00:03:50.000 --> 00:03:57.000
しかし、ここで次の問いが生まれます。地図がオープンになった、では、その次に何が起こるのでしょうか？

1
00:03:57.000 --> 00:04:07.000
では、OpenStreetMapのようなオープンな地図ができたとして、その上にさまざまな情報を載せていくと、どうなるでしょうか。

1
00:04:07.000 --> 00:04:15.000
天気。災害情報。避難所。交通情報。地域のコミュニティ情報。本当にたくさんの種類の情報があります。

1
00:04:15.000 --> 00:04:21.000
そして、すぐに私たちはこう考えます。「これを全部、ひとつにまとめよう。」データを集める。統合する。

1
00:04:21.000 --> 00:04:25.000
そして、ひとつのサービス、多くの場合ポータルとして、ユーザーに届ける。

1
00:04:25.000 --> 00:04:33.000
これは、Web 2.0が私たちに教えてきた、まさにおなじみのやり方です。でも、ここで別の問いが浮かびます。

1
00:04:33.000 --> 00:04:39.000
その統合は、いったいどこで行うべきなのでしょうか？本当に、すべてを中央で統合する必要があるのでしょうか。

1
00:04:39.000 --> 00:04:44.000
私は、世界全体をひとつのデータベースに入れてしまおう、という考え方そのものに疑問を持つようになりました。

1
00:04:44.000 --> 00:04:50.000
現実の世界には、無数の主体がいます。無数の種類の情報があります。そして、無数のサービスがあります。

1
00:04:50.000 --> 00:04:56.000
しかも、それらは常に変化しています。そもそも、現実の世界は、データベースではありません。

1
00:04:56.000 --> 00:05:03.000
だったら、すべての情報を無理にひとつのスキーマに押し込める必要はないのではないでしょうか。それぞれの情報は、それぞれ独立したままでいい。

1
00:05:03.000 --> 00:05:10.000
そして必要なときに、それらを組み合わせればいい。そのほうが、むしろ自然なのではないか。私は、そう考えるようになりました。

1
00:05:10.000 --> 00:05:18.000
そして、ここで地図が面白くなってきます。データの種類が違っていてもいい。情報源が違っていてもいい。

1
00:05:18.000 --> 00:05:27.000
使っているプロトコルが違っていてもいい。それでも、同じ空間を共有することができます。違うデータ。違う情報源。ひとつの空間的なコンテキスト。

1
00:05:27.000 --> 00:05:30.000
地図は、すべての情報を所有する必要はありません。

1
00:05:30.000 --> 00:05:36.000
ただ、異なる情報を同じ場所の上で理解し、組み合わせるための、共通のコンテキストを提供すればいいのです。

1
00:05:36.000 --> 00:05:42.000
そして、これが私が Hyper-Layering Architecture、略してHLA と呼んでいる考え方の基本です。

1
00:05:42.000 --> 00:05:47.000
そして、2011年がやってきました。東日本大震災です。

1
00:05:47.000 --> 00:05:55.000
このとき、それまで私が考えてきた「地図とWeb」の問題が、現実の世界で起こる問題になりました。

1
00:05:55.000 --> 00:06:01.000
その頃には、Web 2.0的なポータルはすでに当たり前になりつつありました。

1
00:06:01.000 --> 00:06:11.000
しかし、災害対応で必要となる情報は極めて多様で、必要な組み合わせも状況によって変わります。

1
00:06:11.000 --> 00:06:20.000
気象情報。被害情報。道路情報。避難所の情報。航空写真。そして、現場にいる人たちから寄せられる情報。

1
00:06:20.000 --> 00:06:26.000
これらすべてを、あらかじめひとつのポータルに統合しておくことは、現実的ではありません。

1
00:06:26.000 --> 00:06:32.000
そのため実際には、情報はそれぞれ別の組織によって、別々に公開されたままでした。

1
00:06:32.000 --> 00:06:37.000
情報自体は存在している。でも、必要なときに、必要な形で組み合わせることができない。

1
00:06:37.000 --> 00:06:44.000
それが、2011年に私が改めて直面した問題でした。そこで私は、これまで考えてきたHyper-Layering Architecture、HLAを、

1
00:06:44.000 --> 00:06:48.000
実際に使えるシステムとして、さらに磨き上げはじめました。

1
00:06:48.000 --> 00:06:56.000
ここで私は、1995年に思い描いていた世界と、現実のWebとの間に、大きなギャップがあることに気づきました。

1
00:06:56.000 --> 00:07:03.000
地図サイトへのリンクを集めることはできます。でも、そのリンクをクリックすると、別のサイトへ移動するだけです。

1
00:07:03.000 --> 00:07:09.000
肝心のレイヤリングができない。なぜでしょうか。その理由は、実はとてもシンプルでした。

1
00:07:09.000 --> 00:07:15.000
私が当初思い描いていたのは、Web上で共通の地図表現が使われる世界でした。

1
00:07:15.000 --> 00:07:24.000
そうすれば、異なる組織が提供する地図情報を、それぞれ独立したまま、ブラウザ上で重ね合わせることができます。

1
00:07:24.000 --> 00:07:30.000
私は、その共通の地図表現をSVGに期待していました。しかし、現実はそうなりませんでした。

1
00:07:30.000 --> 00:07:38.000
地図を表現するデータは、GeoJSONだったり、独自形式のCSVだったり、PNGのタイルだったり。

1
00:07:38.000 --> 00:07:41.000
それぞれが、異なる形式と異なる仕組みで提供されていました。

1
00:07:41.000 --> 00:07:48.000
つまり、Webにはリンクがあった。でも、地図をつなぐための共通のレイヤーがなかった。

1
00:07:48.000 --> 00:07:58.000
これが、1995年に描いた理想と、現実のWeb地図との間にあった大きなギャップでした。そこで私は、考え方をもう一度見直すことになりました。

1
00:07:58.000 --> 00:08:04.000
そして私は、作ることをやめませんでした。実際のシステムで使ってみる。壊れたら、直す。

1
00:08:04.000 --> 00:08:10.000
新しい種類の情報が出てきたら、それも動かしてみる。そうやって、およそ15年間、作り続けてきました。

1
00:08:10.000 --> 00:08:18.000
その間に、HLAは単なるアイデアではなくなっていきました。まったく異なるシステム同士を組み合わせるための、実践的な方法になっていったのです。

1
00:08:18.000 --> 00:08:21.000
そして、そこからさらに、もうひとつ重要なステップが始まりました。

1
00:08:21.000 --> 00:08:28.000
そして私は、このギャップを埋めるために、レイヤーという考え方をさらに一歩進めました。もし、レイヤーが単なるデータではなかったとしたら？

1
00:08:28.000 --> 00:08:33.000
もし、レイヤーそのものがWeb Appだったら？たとえば、天気のレイヤーを、天気のWeb Appにする。

1
00:08:33.000 --> 00:08:40.000
災害情報のレイヤーを、災害情報のWeb Appにする。衛星情報のレイヤーを、衛星情報のWeb Appにする。

1
00:08:40.000 --> 00:08:44.000
そうすれば、データの形式が違っていてもいい。

1
00:08:44.000 --> 00:08:52.000
それぞれの情報が、独自の処理やビジネスロジックを持っていてもいい。それぞれの違いを、Web App自身が吸収できるからです。

1
00:08:52.000 --> 00:09:00.000
そして、レイヤーはデータだけではなく、ロジックを持つ。UIを持つ。ユーザーとのインタラクションを持つ。

1
00:09:00.000 --> 00:09:03.000
つまり、レイヤーそのものが、ひとつのWeb Appになる。

1
00:09:03.000 --> 00:09:09.000
そして、それぞれのWeb Appが、自分の情報を自分の方法で扱いながら、同じ地図の上で共存できる。

1
00:09:09.000 --> 00:09:13.000
これが、私が考えた次のステップでした。

1
00:09:13.000 --> 00:09:19.000
そして、ここで私は1995年のWebの考え方に、もう一度立ち返ります。Webページは、ハイパーリンクでつながっています。

1
00:09:19.000 --> 00:09:27.000
では、もし、地図のレイヤーそのものがリンクだったら？ユーザーがレイヤーを選ぶ。すると、そのリンク先にあるWeb Appが呼び出される。

1
00:09:27.000 --> 00:09:32.000
Web Appがその場で動き、地図上にレイヤーを作り上げる。

1
00:09:32.000 --> 00:09:39.000
さらに、別のレイヤーを選ぶ。また別のWeb Appが呼び出され、そして、そのレイヤーも同じ地図の上に加わっていく。

1
00:09:39.000 --> 00:09:48.000
つまり、Webのハイパーリンクを、地図のレイヤーにまで拡張する。Webにハイパーテキストがあるように、地図にはハイパーレイヤーがある。

1
00:09:48.000 --> 00:09:55.000
ここでは、あらかじめ中央のサーバーが、「この情報とこの情報を組み合わせます」と決めておく必要はありません。

1
00:09:55.000 --> 00:10:04.000
ユーザーが選んだものが、その場で組み合わされていく。統合を決めるのは、中央のサーバーではなく、ユーザー自身なのです。

1
00:10:04.000 --> 00:10:13.000
そして、これは「統合する場所」そのものを変えてしまいます。サーバーではありません。データベースでもありません。ユーザーのブラウザです。

1
00:10:13.000 --> 00:10:19.000
ブラウザが、それぞれ独立したWeb Appを読み込み、同じ空間的なコンテキストの中で、それらを組み合わせていく。

1
00:10:19.000 --> 00:10:25.000
つまり、ユーザーのブラウザそのものが、統合レイヤーになるのです。

1
00:10:25.000 --> 00:10:33.000
では、ここまで説明してきたHLA 2.0を、実際に動かしてみましょう。たとえば、気象情報。

1
00:10:33.000 --> 00:10:40.000
災害情報。交通情報。OpenStreetMap。衛星データ。地域のコミュニティ情報。

1
00:10:40.000 --> 00:10:46.000
こうした異なる情報を、それぞれ独立したWeb Appとして用意します。データの形式が違っていてもいい。

1
00:10:46.000 --> 00:10:54.000
それぞれ独自の処理やロジックを持っていてもいい。そして、ユーザーが必要なものを選ぶと、それぞれのWeb Appが地図上で動き始めます。

1
00:10:54.000 --> 00:11:02.000
異なるWeb Appを、ひとつのMapの上で組み合わせることができる。Many Web Apps, One Map.それでは、実際にご覧いただきましょう。

1
00:11:02.000 --> 00:11:06.000
デモのビデオに切り替えてください

1
00:11:06.000 --> 00:11:13.000
今ご覧いただいたものは、単なるデモではありません。HLAの基本的な特徴は、Independent. Composable. Practical.

1
00:11:13.000 --> 00:11:19.000
つまり、独立している。組み合わせられる。そして、実際に使える。この3つです。

1
00:11:19.000 --> 00:11:25.000
ここには、データウェアハウスはありません。スキーマの統一もありません。中央の統合サーバーもありません。

1
00:11:25.000 --> 00:11:28.000
それでも、まったく異なるシステム同士を、一緒に動かすことができます。

1
00:11:28.000 --> 00:11:34.000
私はさらに、OpenStreetMapからテーマ別の情報を取り出し、独立したレイヤーとして扱う仕組みを作りました。

1
00:11:34.000 --> 00:11:40.000
大規模なテーマ地図を高速に扱うための、QuadTree Composite Tilingといった技術も使っています。

1
00:11:40.000 --> 00:11:44.000
ですから、これは、図に描くときれいに見えるだけのアーキテクチャではありません。

1
00:11:44.000 --> 00:11:49.000
実際に動きます。そして正直に言えば、この規模のことを、中央集権的なサーバーアーキテクチャだけで実現しようとすると、

1
00:11:49.000 --> 00:11:52.000
すぐに、とても難しい問題になってきます。

1
00:11:52.000 --> 00:11:57.000
そして、ここで、AIという新しい技術が登場します。

1
00:11:57.000 --> 00:12:04.000
これまでのGISでは、「機械が情報を理解できるようにするには、データを構造化しなければならない」と考えてきました。

1
00:12:04.000 --> 00:12:07.000
だから、標準化する。データモデルを決める。Schemaを定義する。

1
00:12:07.000 --> 00:12:14.000
そして、そのSchemaに合わせて、データを機械から利用できるようにする。これはもちろん、今でも重要です。でも、AIによって、少し違う可能性が見えてきました。

1
00:12:14.000 --> 00:12:25.000
人間は地図を見て、「ここが浸水している」「この道路は通れない」「この避難所は危険な場所に近い」といったことを、地図そのものから読み取ることができます。

1
00:12:25.000 --> 00:12:33.000
そして今、AIもまた、Map Visualから、空間的なコンテキストを読み取れるようになってきています。そうすると、

1
00:12:33.000 --> 00:12:37.000
「Machine Readableとは、必ずしもデータベースで読めることだけなのか？」という、新しい問いが出てきます。

1
00:12:37.000 --> 00:12:39.000
これは、これまでの構造化データを否定する話ではありません。

1
00:12:39.000 --> 00:12:46.000
むしろ逆です。AIによって、Mapそのものが機械にとって意味のある情報源になっていく。私は、ここにMapの新しい可能性があると思っています。

1
00:12:46.000 --> 00:12:49.000
そこで、もう一度、地理空間データとMapの違いを考えてみます。

1
00:12:49.000 --> 00:12:52.000
これまで私たちは、地理情報を機械が理解できるようにするためには、データを構造化する必要がある。

1
00:12:52.000 --> 00:13:00.000
そう考えてきました。しかし、Mapそのものが、人間にもAIにも理解できるSpatial Contextになっていくとしたら、話は変わります。たとえば、地図を見れば、

1
00:13:00.000 --> 00:13:05.000
どこに何があるのかだけでなく、それが周囲とどういう関係にあるのか、何が重要なのか、そして、いま何が起きているのか、そうしたことまで理解できます。

1
00:13:05.000 --> 00:13:09.000
つまり、Dataだけではなく、MapそのものがContextになる。そして、ここでHLAの考え方が、以前とは少し違う意味を持ってきます。

1
00:13:09.000 --> 00:13:12.000
HLAでは、「中身をすべて統一しなくても、Mapとしてcomposeできればいい」と考えてきました。

1
00:13:12.000 --> 00:13:16.000
これまでは、それを主にWebの相互運用性の問題として考えていました。

1
00:13:16.000 --> 00:13:25.000
しかしAIの時代には、異なるデータを、同じMap Contextの中で組み合わせること自体が、AIにとっても意味のある情報になる。そう考えることができます。

1
00:13:25.000 --> 00:13:32.000
つまり、Data → Map → AI という流れです。私は、これがこれからのMapの大きな可能性のひとつだと思っています。

1
00:13:32.000 --> 00:13:40.000
ここまでが、HLA 2.0の話です。振り返ってみると、私はHLA 1.0の時代から、これをWebそのものの標準にしようとしてしてきました。

1
00:13:40.000 --> 00:13:47.000
W3Cでは、SVGをWeb上の共通の地図表現にできると考え、その実現を目指して活動しました。

1
00:13:47.000 --> 00:13:51.000
日本では、その考え方をJIS X 7197として標準化することもできました。

1
00:13:51.000 --> 00:13:55.000
しかし、SVGがWebの地図表現として世界的な標準になる、というところまでは届きませんでした。

1
00:13:55.000 --> 00:14:00.000
そこで、HLA 2.0では、別の方法を選びました。標準化を待つのではなく、自分で作ってしまう。

1
00:14:00.000 --> 00:14:04.000
svgmapjsというフレームワークを作り、その上にLaWA、Layers as Web Appsを作りました。

1
00:14:04.000 --> 00:14:09.000
そして実際に、非常に多様なWebGISを組み合わせて動かしてみました。

1
00:14:09.000 --> 00:14:15.000
つまり、HLA 2.0では、「これは可能だ」ということを、実装によって証明したわけです。

1
00:14:15.000 --> 00:14:24.000
しかし、その成功によって、逆に新しい問いが生まれました。なぜ、これを特別なフレームワークの中だけで実現しなければならないのでしょうか？

1
00:14:24.000 --> 00:14:27.000
そもそも、なぜWebそのものが、これをできないのでしょうか？

1
00:14:27.000 --> 00:14:36.000
だから私は、もう一度、Webの標準化そのものに挑戦する必要があると考えています。HLA 1.0では、標準を作ることで、それを実現しようとしました。

1
00:14:36.000 --> 00:14:41.000
HLA 2.0では、自分でフレームワークとアプリケーションを作ることで、それを実証しました。

1
00:14:41.000 --> 00:14:48.000
そして次は、その機能を、Webそのものに持たせるという段階です。Webページは、ハイパーリンクによって組み合わせることができます。

1
00:14:48.000 --> 00:14:51.000
ならば、地図も同じように組み合わせられるべきではないでしょうか。

1
00:14:51.000 --> 00:14:57.000
そのために、特別な地図フレームワークを使うのではなく、ブラウザ自身が、地図をハイパーレイヤーとして扱えるようにする。

1
00:14:57.000 --> 00:15:03.000
The Browser Should Be Hyper-Layered.これが、私がHLA 3.0で目指している方向です。

1
00:15:03.000 --> 00:15:08.000
HLA 3.0の目的は、もうひとつ新しい専用フレームワークを作ることではありません。HLAを、Webそのものの能力にすることです。

1
00:15:08.000 --> 00:15:16.000
30年前に始めたこの挑戦を、今度こそ、Webそのものの中で実現できるか。私は、もう一度それに挑戦したいと考えています。

1
00:15:16.000 --> 00:15:23.000
ここで、もう一度OpenStreetMapに戻ってみましょう。OpenStreetMapは、世界の地図をオープンにしました。

1
00:15:23.000 --> 00:15:31.000
これは、本当に素晴らしい成果です。では、その次には何があるのでしょうか？私は、そのオープンな地図の上に、オープンなWebを作ることだと考えています。

1
00:15:31.000 --> 00:15:39.000
異なる組織。異なるデータ。異なるサービス。それらすべてを、ひとつの中央に集める必要はありません。

1
00:15:39.000 --> 00:15:45.000
ユーザー自身が選び、つなぎ、そして組み合わせることができる。OpenStreetMapは、オープンな地図を作りました。

1
00:15:45.000 --> 00:15:54.000
そして今度は、その成果の上に、次のWebを作ることができる。An Open Map Web.オープンな地図から、オープンなMap Webへ。

1
00:15:54.000 --> 00:16:00.000
私はずっと、異なる人々や組織の情報がそれぞれ独立したままWebにつながり、

1
00:16:00.000 --> 00:16:03.000
ユーザー自身がそれらを組み合わせられる、そんな世界を地図の上に実現したいと考えてきました。

1
00:16:03.000 --> 00:16:08.000
一方でOpenStreetMapは、私とは独立に、地図そのものをオープンにしました。

1
00:16:08.000 --> 00:16:18.000
私はそのオープンな地図を土台として、異なる情報やWeb Appを同じ地図の上でどう組み合わせられるかを探求しながら、HLAを育ててきました。

1
00:16:18.000 --> 00:16:26.000
そして最近、HLAは私自身やKDDIだけの取り組みという枠を超えはじめています。

1
00:16:26.000 --> 00:16:39.000
WebDINO Japanの支援のもと、コミュニティが育ち始めていて、より多くのLaWAの開発や、ドキュメントの多言語化といった貢献も生まれています。

1
00:16:39.000 --> 00:16:43.000
HLAは、少しずつコミュニティによる取り組みになりつつあります。

1
00:16:43.000 --> 00:16:49.000
そして今、この二つの独立した歩みが、Webを通じてひとつにつながる時が来ていると思っています。

1
00:16:49.000 --> 00:16:55.000
だから私は、最初の問いに戻ります。What if the Map itself became the Web?

1
00:16:55.000 --> 00:17:00.000
もし、地図そのものがWebになったら？私は、今こそそれを確かめる時だと思っています。

1
00:17:00.000 --> 00:17:05.000
HLAを使って何かを作りたい方は、LaWAを作って、hyperlayering.orgで共有してください。

1
00:17:05.000 --> 00:17:13.000
これをWebそのものの一部にすることに関心がある方は、W3C Maps for HTML Community Groupに参加してください。

1
00:17:13.000 --> 00:17:21.000
OSMが作ったオープンな地図の上に、次のWebを一緒に作っていきましょう。