位置情報の短縮符号化


符号化 = エンコード
逆符号化・復号化 = デコード

データ変換の領域にちかい話だが以下のように幾何情報をクライアントに持ってくる際に役立つ可能性のある情報
– 続 – ArcGIS for Serverフィーチャの受取

座標値を符号・短縮化することで、容量削減が可能 (緯度経度に特化した仕組みが多い)
ただし、メッシュグリッドの概念なので基本的には精度が丸まってしまう。
※データコミットに使用する (編集してDB格納する) データには使用できない

色々なやり方があるのでとりあえず適当に紹介

符号化の仕組み自体で特許 (画像圧縮技術のように仕組み自体は特許化可能)がとられている
場合があるので公開サイトや商用利用時は注意が必要だと思われる。
TXT自体は、Webサーバの動的圧縮機能によってgzip圧縮がかけられるので圧縮処理コストを
支払えば容量削減自体はできるだろうが、もともとの容量を減らす方法の検討としては有効か。

基本用途は、QueryStringによってURLが長くなることを防ぐ目的で使用されている。
Googleに限っていえば、ライン頂点座標の圧縮目的となっている。
ネットワーク帯域圧迫⇒許容人数の低下。
性能検証も複数人想定が必要

Google Mapsの符号化の仕組み
https://developers.google.com/maps/documentation/utilities/polylinealgorithm?hl=ja

ジオポ -仕組み-
http://geopo.creco.net/intl/ja/developer/

ジオポ -サンプル-
http://geopo.creco.net/intl/ja/developer/sample_code.html

ロカポ -仕組み-
http://www.locapoint.com/jp/
http://www.locapoint.com/jp/spec.html

ロカポ -サンプル-
http://www.locapoint.com/jp/samplecode.html

ジオハッシュ
http://ja.wikipedia.org/wiki/%E3%82%B8%E3%82%AA%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5

「Encoding Latitudes and Longitudes」「Compact text lat lon」などで検索すれば他にも出てくる

地理情報はWebで扱い頂点座標が必要な場合、仕組み上、ストリーミング配信の動画のように配信を待つべきなのかもしれない。
しかし頂点が必要であると言う事は、複数ユーザ更新される可能性のあるデータ(でなければ固定画像でよし)なので、動かすたびに差分問い合わせが必要となる。
(プッシュ通信と言う手も考えられなくはないが)
メモリに乗りきるのか?と言う根本的な話も戻ってきて、じゃあやっぱり移動都度リクエストが無難?
ローカルストレージの制限は?範囲でクエリするにはメッシュ起点が必要になる?

いろいろ考えだすと難しい、結局差分更新のためにDB層で仕組んでおいて受け渡しがベストな気がする。

カテゴリー: 設計 パーマリンク