問題設定
大量の現金の流れを掴んでいないプレイヤーが三年後のウェブ地図に備えて考えるべきことを整理し、自分のスタンスとして晒すことで新たな議論を得る。
- 結局、スタンスを持たないのは卑怯だから
- スタンスはいつでも更新してよいから
選択肢
大量の現金の流れを掴んでいないプレイヤーの選択肢
- 大量の現金の流れを掴む
- 大量の現金の流れを掴んでいない前提で戦略や戦術を考える
私の場合は 2. を選択。
状況分析
大量の現金の流れを掴んでいないことを前提とするということは、ウェブ地図の運営自体が本業という訳ではないですね。本業を支えるという性格でウェブ地図を運営するというわけだ。
本業の目的・目標をよく把握することは大事で、それが戦略につながるが、ここでは戦術のみを考える。
ただ、これだけは記しておく
本業に寄与しない機能は削るべき。
- その機能、もっと正しく実装できる人が他にいるから。コラボの芽出しを阻む。
- 真剣を振るえない機能の混入は全体の質を下げるから。顧客に失礼にあたる。
- どうしてもやりたいなら、それは本業に寄与するのかもしれない。あるいは、本隊と分離して試行してはどうか。
戦術考案の判断要素
- Web GL の主流化完了
- 2D と 3D を融合して提示したほうが経済的に
- モダンウェブが普通になる
- fetch とか promise とかコンポーネントとか普通になる
- 扱うデータ量は増え、転送技術は進展する
- 同時アクセス数というよりは一ユーザあたり転送量に対してもスケールせよ
- その意味でもオフラインキャッシュ主流化
戦術案
- 基本モデルを踏襲して近代化改修
- レイヤメタデータ、タイル、目録
- これにオフラインキャッシュをビルトイン
- モダンウェブで作り直し
- UI はどうする？
- 3次元と2次元の一枚化はするが、ボタンの配置程度は直しても基本構成は踏襲
- UIとボンネット下を同時改修しない
現時点での部品候補
このスライドはいつでも豹変する可能性あり
- 標高タイル対応した Mapbox GL JS 又はベクトルタイル対応した Cesium
- Service Worker 系活用
- 軽めの Web Components 活用
- サーバサイドは引き続き回避
- 使っても lambda
入れるべきとは思いにくいもの
- パーソナライズ；大量の現金の流れを掴んでいない場合には、止めたほうが経済的に回る可能性が高まる。
- ストーリーマップ；まだまだ当面、語るのはサイトじゃなくて人でありスライドだろう。
このスライドには、言わずもがなのことも書いておく。
オープンな課題
- レイヤメタデータ肥大化問題
- しかし各人が必要なレイヤ数は少数
- でも大量の現金の流れを掴んでいるわけではないので、パーソナライズは回避
- レイヤ情報の集め方、読み込み方、回し方
- レイヤメタデータの標準化はまだ進まないだろう。タイルの主流化完了待ち。
- バイナリベクトルタイルスタイルの設定自由度の制御（ゲームバランス的な意味で）
さらに挑戦的になる場合に参考とすべき作品
- iD editor
- つまり作図です。
- Maputnik
- 状態の扱いとかの部品取り。
蛇足
通常、大規模な地理空間情報はバージョン管理するべきものじゃない。時系列バックアップするべきものだ。
バックアップの思想に立った上で、効率的にバックアップする方法を洗練させよ。
おおむね、TimeMachine と似たような思想に結果的になる。また、目録とも思想が似る。
書いてみた感想
- 私は思ったよりオフラインキャッシュを気にしている
- 単に外出用じゃない。日常使用の高速化に使うつもりだ。
- 結局、アプリに迫ることを意味しているのだろう。
- 投影の話が出てこなかった
- 積極推進というよりライブラリ待ち
書いてみた感想 Cnt'd
- 国際化にはコストをかけるのか？
- 結構、私はパターンを知っている。