OpenLayers と Leaflet の最近の動向について

hfu @_hfu_

@kochizufan なにかすごく劇的な路線変更な感じがしますね ^_^ 情報発信を楽しみにしています！

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ レンダラ依存しちゃいますねどうしても。canvas及びWebGLレンダラは、DL単位はタイルなんですが描画は広い座標系の一部に転写なので、画面上に出る時は一枚絵になっちゃうのでどうしてもベクトルは維持できない。

hfu @_hfu_

@kochizufan えー、それはまた非スケーラブルな感じがします、というかなんか丸め誤差とかタイル境界を伝搬しちゃわないかと心配になります。自分が作った canvas tile テストを復習しています http://t.co/CTdmDYeqnf

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ 一方でDOMにもスマホ版のタッチ操作には致命的な弱点があって。連続ズームで操作してると、ズームが切り替わって指の下のタイルdivが切り替わった時点で、touchmoveイベントが途切れちゃうんです。MMとOL3のDOMレンダラは、これを解決できてなくて動作がおかしい

hfu @_hfu_

@kochizufan 私は http://t.co/EiIvyrnDQz みたいな馬鹿正直な canvas 対応が好きです。canvas もタイルで分かれてますよ的な（実装ではどうなっているか確認していない）。

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ LeafletとGoogle Maps APIは、ピンチインアウト中はタイルではなく画面全域を一枚絵扱いでアフィン変換して、touchend後に改めてタイル描画する事でこれを回避してますけど、このやり方は中間（小数点）ズーム許容に向いてなさそう。

hfu @_hfu_

@kochizufan 私のベクトルタイルのイメージは、 http://t.co/EiIvyrnDQz の drawTile が呼び出されて、その処理の中でベクトルデータを get して、馬鹿正直にレンダリングしておしまい、的なものですね。たぶん関数内でスタイルを適用する。

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ なのでtouchmoveイベントの継続性の問題で、スマホでのタッチ操作のUX向上を考える限り、DOMレンダラを使い続けるのにはちょっと無理があるんじゃないかという印象は持ってます。

hfu @_hfu_

@kochizufan なるほど

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ 非スケーラブルで、実際Android4.0のネイティブブラウザでは最近までうまく動きませんでしたね。動くようになったのは、一枚板ではなく小さい座標系のcanvasレイヤをいくつも用意して使い回す実装に変更したらしく、それ以降でした。

hfu @_hfu_

@_hfu_ . @kochizufan その発想なら、レンダラー考える前にまず「馬鹿正直ベクトルタイル」（ローデータをタイル分割してWebメルカトル・タイル内整数座標にしたもの）を作ってから考えるべきでしょうね。零度のWebマッピングの発想で、XYZタイルで、ということか。

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ ただ、UXを重視すると、少なくとも画面全体は同じDOM要素にしておかないと切り替わり時にtouchイベントが途切れる、という認識はあるようで、そのため全体をcanvasの小タイルに分けるような実装にはなってないですね。

hfu @_hfu_

2010-06-15「零度のウェブマッピング」→2012年に「四分木タイルにするだろう」というセルフブックマークをしている。→2013年に「馬鹿正直ベクトルタイル」を作ろうと思っている。 http://t.co/6t6gg3tnB3

hfu @_hfu_

命名訂正「馬鹿正直ベクトルタイル」→「愚直ベクトルタイル」

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ もしかしたら、全域「htmlとしてはSVG要素」で、その中で子SVGをタイル呼び出しで突っ込んで行くような形なら、可能なのかもしれませんね。判らないですけど。

hfu @_hfu_

@kochizufan 会心→「一枚板ではなく小さい座標系のcanvasレイヤをいくつも用意」たぶん、まさに地図タイル工法の真髄をついてる

hfu @_hfu_

@kochizufan なるほど→「少なくとも画面全体は同じDOM要素にしておかないと切り替わり時にtouchイベントが途切れる」

hfu @_hfu_

@kochizufan g 要素がタイル的に並んでいる実装が予見できますね。img を管理するように g を管理するのかな。（てきとう）

こちずふぁん (大塚恒平) @kochizufan

@_hfu_ あ、でも先に書いたようにタイル単位ではないですよ。あと、使い回し時の初期化にミスってるようで、常に書き変わる世界系タイルだと問題ないんですが、一地域だけの地図とかで使うとあちこちに使い回したゴミがwモンキーパッチで対処して、本家で直ってるかは未確認。

Kozo Kamada @geo80k

@_hfu_ @kochizufan それは、タイルサイズが小さい場合において、個々のタイルが拠って立つ座標系のバリエーションが多彩になるべき、という意味ですか？例えば公共測量の基準よりもずっと多くの平面直角座標系を使うとか？

hfu @_hfu_

@geo80k @kochizufan 私の場合は全く逆で「多様な座標系が存在するのはサーバまでだよね～」というスタンス。ブラウザはWeb Mercator支配で、タイル内はタイルオフセットを消去した(0,0)-(255,255)座標系に固定する。ネジの如き標準化が求められている

こちずふぁん (大塚恒平) @kochizufan

@geo80k @_hfu_ あ、そうではなく、OL3のcanvasレンダラの実装が、メモリ内に超でっかい(-180,86)〜(180,-86)（もちろん実際はメルカトル座標）の描画空間（多分）を準備して、その中の見えるところだけタイル画像を描画するような実装だったんですよ。

こちずふぁん (大塚恒平) @kochizufan

@geo80k @_hfu_ すると、大半は見えない領域なのにメモリ空間だけは食うので、Android4のネイティブブラウザとかではとても動くもんじゃなくて。なので、小さな表示領域のcanvas要素をいっぱい用意して、表示領域が変わると消えた部分を使い回すような実装で軽くなった

こちずふぁん (大塚恒平) @kochizufan

@geo80k @_hfu_ という話です。実は完全にソースを追った訳じゃないので、最初の実装が本当にextent全域座標系だったかは確かめてないのですが、以前から使い回す系だったにしても、その使い回す単位を劇的に小さくしたのは確かです。

こちずふぁん (大塚恒平) @kochizufan

@geo80k @_hfu_ ある時から突然Android4でも動くぐらい軽くなって、同時に表示領域を切り替えた時に突然関係ない場所のタイルのゴミが表示されるバグが発生し出したので、ああ、これは小さなcanvas要素を使い回す実装に変えて、使い回す際の初期化に失敗してるなと。