Skip to content

Instantly share code, notes, and snippets.

@keiono
Last active January 1, 2016 00:29
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save keiono/8067196 to your computer and use it in GitHub Desktop.
Save keiono/8067196 to your computer and use it in GitHub Desktop.
D3.js Advent Calendar 2013 Day 21: D3.jsと周辺ツールを使ったデータの可視化

アプリケーションとしてまとめる

D3.js Advent Calendar 2013の21日目の記事です。今回はD3.jsのフォーマットや詳細技術というより、もう少し俯瞰的な視点で書いてみます。D3.jsを使う理由は、もちろん何らかのデータを可視化したいと言うことでしょうが、最終的にどのようなアプリケーションとしてまとめるかと言うゴールにはかなり幅があると思います。しかしそれでもいくつかの共通する課題が存在します。

テーブル形式のデータや、先のツールで書きだしたJSONなど、データを整えてD3.jsで使える形式として用意する事自体はそう難しいことではありません。手作業でスプレッドシートを使って作成してもいいし、スクリプト、もしくはOpenRefineなどといったツールで作成する方法もあります。そして一度D3.js内で扱える形式のデータが得られれば、それを様々な方法で可視化出来ます。そこから最終的な可視化を作成するプロセスで考えるべき事は次の二点でしょう:

  1. 最終的なアプリケーションとしてどうまとめるか
  2. そのアプリケーションを構築するモジュールの実装

この記事では、この2つについてまとめます。

適切なツールを適切な場面で使う

D3.jsのターゲットプラットフォームはモダン・ブラウザです。そしてそのプラットフォーム上では現在凄まじい勢いで各種可視化/グラフィックス関連ライブラリがオープンソース・ソフトウェアとして開発されています。D3.jsは非常に強力なツールですが、使い所を間違えると結果は同じなのに余計な労力がかかっただけ、と言う事にもなりかねません。最終的な目的はD3.jsを使うことではなく、データの理解を助けるアプリケーションを作成する事なので、より少ない労力で同じことが可能ならばそちらを使うほうが良いはずです。ではD3.jsが最も力を発揮するのはどんな場面かでしょうか?それは、複雑なインタラクションが必要な場合や、既存のツールやパターンでは表現しきれない可視化のアイデアがあるときです。

ただし、こういった複雑な可視化をD3.jsで作成する時にスクラッチから作ることの非効率性は多くの方が気づいているので、それを解決する試みもいくつかあります。(ちなみに、D3.jsの作者であるBostock氏もこの問題には気づいており、こんな記事も書いています。)

再利用可能な形でレンダラーを作成する

D3.jsの強みを利用して作成された高度にカスタマイズされたチャートを公開する場合、自己流で一回限りの物を作成するのもひとつの方法ですが、どうせならばそれを再利用なコンポーネントとして作成した方が後々便利です。こういった用途に使えるフレームワークには、Misoと言う日本人から見ると微妙なネーミングセンスのプロジェクトで作られているd3.chartがあります。これは再利用可能なレンダリングのためのコンポーネントをD3.jsで作成し公開するための小規模なフレームワークです。

d3.chartは比較的親切なチュートリアルがありますので、詳細は割愛しますが、先日の記事の最後でも触れたような、「同一のデータを小さなレンダラの集合を用いて様々に形へ可視化する」と言う思想に基づいていますので、「どう再利用可能なコンポーネントを書いていいのかわからない」と言う場合にはまずこれを使って作ってみるのもひとつの手です。

既存のモジュールをextendして改良したり:

d3.chart("BaseView").extend("CustomView", {
  initialize : function() {
    // 初期化コードをここに書く。
  },
  //...
});

ミックスインを用いて、小さなレンダラの集合として一つのモジュールを組み上げるような仕組みが用意されています。単純な例では、軸とバーを別々のレンダラとして実装し、それをmixinしてバーチャートとして仕上げる、と言う感じです:

d3.chart("AxisRenderer", {
  //...
});

d3.chart("BarRenderer", {
	//...
});

を組み合わせると:

d3.chart("BarChart", {
  initialize: function() {
    this.axis = this.mixin("AxisRenderer", this.base.append("g"));
    this.bars = this.mixin("BarRenderer", this.base.append("g"));
  }
});

と言った感じです。薄いフレームワークで比較的わかりやすいですが、モジュール化を行うには様々な方法がありますので、基本原則(同一データモデルを維持しながら小さなレンダラの組み合わせで可視化する)さえ守れば、色々と工夫してみるのもいいでしょう。

D3.jsと組み合わせて使うと便利なライブラリ

このように、自分で作らないと表現できない部分はD3.jsの再利用可能なコンポーネントとして実装し、定型の部分(パイチャート等)はもう少し高レベルなライブラリで作り、最終的なアプリケーションに仕上げるのが効率が良いです。以下はほんの一例ですが、JavaScriptで実装された便利なライブラリです

チャートの描画

棒グラフ、折れ線グラフ、パイチャートといったものはスプレッドシート等でもサポートされている基本的なものですから、単純にそれが使いたい場合は高レベルのライブラリを利用してしまったほうが早いでしょう。

グラフの描画

グラフ(ネットワーク)描画にも様々なツールが有りますが、これもD3.jsのforceレイアウトで一から作るよりも、グラフデータに特化してあるライブラリを利用した方が簡単に書ける場面が多いです。

  • sigma.js - レンダリングの自由度は低いがハイパフォーマンスで、大規模グラフの一括描画に向いています
  • cytoscape.js - 手前味噌で申し訳ないですが、我々の作成しているグラフ描画に特化したライブラリ。階層構造(Compound Node)の描画などにも対応

地図の描画

最近は位置情報が盛んに使われるようになってきたため、地図へのマッピングに特化したライブラリも増えてきました。

スクラッチからの作成

  • processing.js - Java版で有名なProcessingの移植。比較的ローレベルな描画に特化してあるので、基本的には自分で一から作る時に使います。元々はメディアアート系の利用を念頭に作られていますので、データ可視化に使おうとすると、かなり自分で書く分量が多くなってしまいますが、その自由度が必要な時に。

結論からデザインする

なぜ可視化を行うのかと言えば、当然そこに表示すべきデータがあるからです。ただしD3.jsはなまじサンプルが充実しているために、これが「そこにツールがあるからだ」になってしまいがちです。これを避けるにはどうしたらいいのでしょうか。私は可視化自体の研究者でもなく、必要に応じて既存の研究結果やトレンドを追いかけているだけですが、こういったものを作る時に最も大事だと思うのは、最初に伝えるべき結論を決定し、それに添ってデザインや実装を開始するということです。そうしないと、結局CSVファイルをExcelで開いた時と比べてもたいして理解の助けにならないなんてことになってしまいます。抽象的な言い方になってしまいますが、D3.jsをその結論を述べるためのツールとして使うことが最も効果的なD3の利用方法でしょう。

さて、可視化アプリケーションのデザイン原則などは、それだけで何冊もの本になるくらい大きなトピックなので、興味のある方は以下のような定番の本や論文を読んでみてください:

この教授のスライドや著作は非常に参考になるため一読をおすすめします:

(残念ながら、データ可視化という分野の文献は圧倒的に英語のものが多く、この分野に挑戦しようとすれば基本的に英語は避けられません...)

またまた手前味噌で申し訳ないですが、私がワークショップで使った資料にもその辺りのことを書きました。英語ですが、平易な表現のみですので興味のある方は眺めてみてください:

まとめ

本質的に全ての可視化アプリケーションやライブラリは、たったひとつのことをしているだけです。それは、データを視覚要素にマッピングする事です。ここでいう視覚要素とは、色、線分の長さ、形、位置などといったものを指します。全てのライブラリは、その作業をより抽象度の高いレベルで行う事ができる手助けをしているだけとも言えます。従って見方によっては、D3.jsは生のSVG構文に対するシンタックスシュガーの集合とみなすことも出来ます。各ライブラリがどの抽象度でデータを扱っているのかを理解して、その使いどころを見極めることにより最短の時間で最大限の効果を得ることが出来ると思います。

私事ですが、私のバックグラウンドは計算機科学です。しかし全くコンピュータグラフィックスの高等教育を受けたことがありません。それでも最近の急激なオープンソースツールの進歩により、素人ながらかなり様々な事をそれなりに短時間で形にできるようになってきました。英語に躊躇せず最新のツールや文献にあたってみると、結局は一番の近道になると思います。私は元々専門でないことを必要に迫られて行っているプログラマに過ぎませんので未だ勉強中ですが、また便利なものの発見があった時には記事を書いてみたいと思います。

sample

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment