方向性
新技術を Cartography に取り込むために引き続き進む。ただし、その仕事は一人の手には余る。このため、自分の行うべきことをより精密に位置づける必要がある。
取り組みの階層性
- デジタル地図に対する FUD を排除する
- ウェブ地図に対する FUD を排除する
- タイル地図に対する FUD を排除する
- ベクトルタイル地図に対する FUD を排除する
- バイナリベクトルタイルに対する FUD を排除する
FUD を排除するには、おそらく「実際にできることを示す」しかない。また、排除には予防を含む。
バイナリベクトルタイルと小縮尺の問題
バイナリベクトルタイルと小縮尺の問題について、どのように取り組むか。その前に、主攻と助攻を明確に分離しておく必要がある。
バイナリベクトルタイルの重点は常に大縮尺にある。大縮尺において属性が取得でき、属性からウェブの他の情報にリンクできること、これがバイナリベクトルタイルの本質的重要性。
小縮尺は経済性を無視すれば他技術で代替可能。
バイナリベクトルタイル小縮尺問題
バイナリベクトルの小縮尺対応はあくまで助攻。
- 小縮尺でデータが混み合いすぎる問題
- そもそもデータを見せないことで対処
- 画像タイルをハイブリッドして対処
- ベクトルレベルで総描して対応
- 投影法問題
- ベクトルは問題ではなくて解法
小縮尺でデータが混み合いすぎる問題
本稿の主題ではないが、整理すると次のとおり。
- そもそも小さすぎる縮尺でデータを見せない工夫をすることが早道である。
- 塗り系データで詳細さを表現する狙いがあるならば、画像タイルをハイブリッドする。
- ベクトルレベルで総描して対応するのが正攻法であるが、これは大きな仕事を生む。
小縮尺投影法問題
こちらが本稿の本題。まずは大勢を整理。
- そもそもバイナリベクトルタイルに限らず、タイル地図全般の問題。
- しかしウェブメルカトルに対抗しようと考えることすらすべきではない。
- ウェブメルカトルは単位平面を四分木で分割する手法を含む。
- データの相互運用を阻害すべきではない。
- 小縮尺において、最も避けるべきである不連続を発生させず、最も事業意義が高い大縮尺において投影上の問題がない。
小縮尺投影法問題の解法
- 大縮尺との連結性を保つ
- ウェブ地図ライブラリの拡張を意味する。
- 大掛かりになる。
- 決め手となるものがないのでは。
- 大縮尺との連結性を断つ
- 投影した画像（好例：Polar Stereographic の例）を無理にウェブメルカトルに乗せる方法は、プラクティカルではあるが、行き詰まりを意味する。その先の展開がない。
- d3.js でやられているような投影法の導入が有望。ベクトルが前提となる。
この先の展開
- d3.js での投影技術を使う。
- できればこの技術のデータソースにバイナリベクトルを使うことができるようにしたい。
- 上記の実証済み技術を使うか、あるいは単純にベクトルデータのソースとして最初に読み込むだけに留めるか。
（蛇足）毘
上杉謙信の旗印の「毘」は、毘沙門天の毘であるという理解に留まるべきではなく、「毘」の一字自体が「たすける」、「増す」、「厚い」、「へそ」、「連なる」という意味があるということを理解すると良いのではないかと思った。上記本文で「助攻」と書く時に気がついたもの。