SVG地図のユーザインタラクションについて(@Magepa)
SVGにするなら、拡大縮小がクライアント側でできるのがアレなわけで、サーバのスクリプトでそれを生成するのは正しいのか？WEB的には細かいのつくっといて違う縮尺を要求されたときにキャッシュで返すみたいなことができたらうれしい希望的観測
— まげわっぱーさん (@Magepa) 1月 8, 2012を踏まえて、２つのことを考えてみる。あまり結論的なところには至っていないが、パラフレーズとして。
http://zero-degree.heroku.com/ のやり方について、この知見を適用してみると、２つの解釈ができるように思った。
- 拡大縮小によってスクリーン座標はクライアント側で変更できるのだから、サーバ側で整数のスクリーン座標に変換して渡すのは正しいのか。Web的には細かい座標が入ったものを作っておくべきでは。
- SVGならばクライアント側で拡大縮小ができることが売りなのであって、（サーバ側で生成した）Raphaelの（クライアント側）スクリプトで（SVG文書を）生成するのは正しいのか。
前者については、レスポンスのサイズや、拡大縮小への対応の仕方によると思っている。もっと深いレベルでの設計が必要だ。この方向については、ベクトルタイルベースである Android 版 Google Maps を持っている Google だけが実践的なノウハウを持っているのではないだろうか。OpenLayers の SVG 対応以上の深いベクトルタイル処理の設計を考える必要がある。必要があると思いつつ、手近な実装がないという人が多いのではないか。あるいはインフラ層の規約が少なすぎると思っている人が多いのではないか。
Raphaelは、ブラウザ内部で SVG 文書を組み立てているようである（要確認）。ブラウザ内部で組み立てられた SVG 文書に対して、SVG 拡大縮小のブラウザレベルユーザインタフェースは使用できるはずである。むしろ、本質的な問題は、ブラウザにおいてSVGデータの拡大縮小のユーザインタフェースが組み込まれていないところである。例えば、video タグに対しては再生関連のユーザインタフェースがブラウザから供給されるが、svg タグに対しては拡大縮小関連のユーザインタフェースはブラウザからは供給されない。
このエントリはパラフレーズにとどまるが、できることならこの方向についても考えを進めていきたい。
