JA:True Offset Process
True Offset processは、下記の問題の解決を図るものです:
- すべてのトレース用背景画像が、正しく位置合わせされているわけではない。
- 多くの(殆どの?)ユーザーは、エディタが、背景画像の位置合わせを補正することができることを知らない。
- 背景画像を正しく位置あわせしたいとユーザが願っても、信頼できる位置合わせ情報を得にくいことが多い。
- マッパー(ユーザー)によって、背景画像を位置補正なしで使ったり、異なる位置合わせで使うために地図データの品質が低下する。
- 一人のユーザにおいてさえも、位置合わせに一貫性を持たせることは難しい。というのも、編集セッションの度に、手動で画像を正しい位置に合わせることが必要だ。
True Offset は、人手による背景画像の位置合わせ作業の自動化を行います。
そのために、入手可能な最良の情報に基づいた位置決めが行われます。
プロセスは以下を定義します:
- 位置ズレが判明している区域に関して地図上にズレを記録する方法
- 編集ソフトウェアがTrue Offset Webサービスに以下を問い合わせる方法:
- 表示対象の図に位置補正を加える必要があるか否か(位置ずれがそもそも存在するか)
- 必要な位置補正の量
- 表示中のズームレベルに加えて、既知の補正を問題なく適用できるズームレベルの範囲
- 地図のどの区域にその補正を適用することが可能か
既知のズレを記録する方法
信用できる(trusted)情報が信頼できる方法で(reliably)入手できたなら、 補正の必要性を判断できます。必要な補正量は北と東の方向を正方向として、度単位で 表現します。つまり、正の東のオフセットは、背景画像が補正なしでは東にずれた場所に 表示されることを意味します。(注:JOSM はオフセット値を逆の符号で表示します。 正の東向きオフセット値は、画像を補正なしで表示すると、西にずれた場所に表示されることを 意味します。)
背景画像のソースはたくさんあるので、どの補正値も、どの画像に対してのものなのかを 明確にする必要があります。それに加えて、エディタが表示するズームレベルによって 用いられる画像が切り替わり、その結果、補正量も切り替える必要が生じることが生じます。
このプロセスの最初の実装方法としては、オフセットを、オフセットの適用対象と判断される区域を 囲む way として、OSMのデータベース自体に記録することが提案されています。 単一のバッチから得られるバッチではオフセット値の要求は多くの場合同一であると予想されています。 補正対象区域の輪郭のwayには、以下に提案されている体系で補正量を示すタグがつけられます。
多くのマッパーが、OSMデータベース自体に、補正量対象区域を示す輪郭を格納することに 異論を唱えています。最終的には補正情報は別の場所に格納されることになるかも知れません。 しかし、プロセスの実証試験(proof of concept)としては、JOSMの中にデータを記録する ことにより、マッパーは、習熟したツールを用いてアプローチの検証をすることができます。 本プロセスは、OSMがこれらのデータの格納場所となりつづけることを前提とするものではありません。
タグづけの体系
Key | Value | Element | Value |
---|---|---|---|
calibration | area | このタグは、ウェイが囲む区域の目的を示すもので、これにより、XAPI経由で情報を取得できるようになります。
将来制御ポイントの補正が必要となった場合には "point" か "node" という値を使うことが考えられます。 | |
data_provider | bing / yahoo / landsat / ... | エディタが補正情報を探す際に画像のファミリを識別するための識別子。 | |
area_name | テキスト | 画像の当該バッチについて説明する、人間向けの自由形式のテキスト。
このタグを "name" としてしまうと、name rendering になってしまう恐れがあるので、 nameという名前にはしません。 | |
zoom_min | 整数値 | 当該補正量の適用対象と判断される、(OSM用語で言うところの)ズームレベル。
低いズームレベルでは異なる画像が使われることが多いので、補正を記録する 意味がないことがあります。 | |
zoom_max | 整数値 | 当該補正量の適用対象と判断される、(OSM用語で言うところの)ズームレベル。
オプションであり、役に立つケースは稀と思われます。 | |
offset_north | 実数値 | 元の画像を北にずらす必要がある補正量を、度を単位としてあらわしたもの。
画像を南にずらす必要がある場合には負の値となります。 オプショナルであり、省略された場合には、画像が南北方向には正確に位置合わせされているものとみなされます。 これは、JOSM Imagery moduleにおける Offset Northing と同じ意味を持ちます。 | |
offset_east | 実数値 | 元の画像を東にずらす必要がある補正量を、度を単位としてあらわしたもの。
画像を西にずらす必要がある場合には負の値となります。 オプショナルであり、省略された場合には、画像が東西方向には正確に位置合わせされているものとみなされます。 これは、JOSM Imagery moduleにおける Offset Easting と同じ意味を持ちます。 |
例
Web サービス
(本プロセスが必要とする)Webサービスの実装の詳細は今後変遷するであろうが、 webサービスへの期待は、すべてのオフセット情報が記録されたされたローカルなPostGIS データベースを保持することである。 Webサービスは基本的に RESTful スタイルであり、 もっぱらエディタソフトウェアから、次のような感じのリクエストを受ける:
http://offset.openstreetmap.org/1.0/offset/bing/17/53.1234/-6.1234
http://offset.openstreetmap.org/<version>/offset/<data_provider>/<zoom>/<lat>/<long>
devサーバ上で配置されている現状に即して言うと、サービスは以下のように呼び出せる。
http://mackerski.dev.openstreetmap.org/offset/1.0/offset/bing/20/53.26/-6.67
本サービスをサポートするツールは、現行のテスト用のURLも、提案されている正式なURLの 双方に対応できるように、URLの表現を設定できるようにしておくことが推奨されている。
data_provider は先に述べたとおりである。zoom level はエディタが表示しようとしている 画像タイルのズームレベルである。 lat と long は、エディタウィンドウの中心の座標である。 画像はこの中心座標を基点として補正される。バージョン番号は、このインタフェースの今後の 変更に備えてのものである。バージョン番号として1.0がクライアントから要求された場合には、 返却されるデータは下記の通りである。今後、互換性のない形式のレスポンスを返す必要が 生じた場合には、より大きなバージョン番号を定義することになる。
webサービスは、リクエストにマッチするオフセット情報のポリゴンがないか検索し、 返事をXMLか、もしかしたらJSON形式で返却する(詳細未決定)。 内容は下記の通り:
条件 | 返却データ |
---|---|
該当オフセットデータなし | これはすなわち、要求された座標が含まれるオフセット情報がないか、あったとしても、ズームレベルが
違うことを意味する。この場合には、適用可能なオフセット情報がないことを意味する、殆ど空の レスポンスを返す。レスポンスには、周囲の少なくともこの範囲にはオフセット情報が存在しないと 分かっていることを示す矩形の座標情報も含まれる。このレスポンスを受け取ったら、要求を送った アプリケーションは、背景画像の座標を補正せずに使用する。矩形の座標データは少なくとも一日 キャッシュしておき、該当矩形領域に対して不要なルックアップの発生を防ぐべきである。 |
オフセットデータが一つ存在する | これはすなわち、要求された座標とズームレベルに対応する補正情報が一つだけ存在していることを意味する。この場合には、必要な北向きと東向きの補正量が返される(もし存在すれば。データが存在しない方向に関してはデータは正確であると仮定する)。返却された補正量が適用可能な最大の "水平面内の" 矩形領域も帰される。
この補正量がそのまま適用可能なズームレベルも返却される。レスポンスを受け取ったアプリケーションは 結果を少なくとも一日キャッシュし、矩形で示された領域内へのルックアップの発生を防ぐべきである。 |
オフセットデータが複数存在する | これは、上記のキャッシュの仕組みがうまく機能しなくなるので、好ましくない状況である。
そのため、オフセットデータは、領域においてもズームレベルにおいても重なることは好ましくない。 しかし、マッパーが注意深く作業したとしても、オーバーラップ領域が多少は生じてしまうことが考えられる。 複数見つかったオフセットデータのうち、矩形領域がもっとも小さいデータがオフセットデータとして 返却されるべきである。 |
課題
- 異なるオフセットが必要な区域の間の界面における挙動の定義が不十分である(エディタの実装での課題)
- 最大の効果を発揮するには、このプロセスを個々のエディタがサポートしないといけない。
- エディター作者や、オフセットを記録するマッパーは、data_providerに、標準化された値を用いなければならない
- 大きな画像に完全に包囲された島状の区域(enclave)が、周囲と異なるオフセットを必要とすることが考えられる。現在考えられている方法の延長では、外側の区域を分割する必要があるだろう。というのも、「穴」はサポートされていないし、区域が重なるとキャッシュの方式が破綻してしまう。
- 例えば5mといったズレのあるままデータ入力をしていたマッパーは、(誰かが位置補正を入力して)ある日突然、自分の入力データと背景画像がずれたのに気づいてびっくりするかも知れない。
- 意味分かる人翻訳をお願いします:Need to decide whether the areas bounding imagery batches should be drawn where the imagery wishes to be placed or around the corrected positions. (not that big a deal, but we should recognise that this is not yet defined)
- この方式が適用されると、どのエディタも補正情報のwebサービスをアクセスし始めるので、webサービスの負荷を考慮する必要がある。
- 入力したての補正の効果をマッパーが確認するために、キャッシュにローカルに変更を加える機能(cache-dirtying logic)が必要だったりしないか?
- 残念ながらこれは、動き回る的を追いかけようとする愚かな回避策である。現実的な解はない。(Unfortunately it's a fool's errand chasing a moving target. We have no control or real knowledge of the underlying data. It simply can't be done in a practical sense.) See the Talk side of this page for why.