[OSM-ja] ローソンデータインポート、マージ手順案(was Re: 全国ローソンデータのテストインポートについて)

2013年 9月 13日 (金) 19:32:02 UTC

いいだです。

完全に個人の意見です :3

> としさん
> このインポートデータの位置精度は、GPSのDOP(HDOP)ではどれくらいでしょうか?
すみません、具体的な数字はすぐにはわからないので、問合せをしています。

> また、絶対精度が良い場合、HDOPがさらに良ければその方を採用するという事ですね。
> つまり、インポートデータより私の自作ロガーの方が精度が良いならそれを採用するという事で良いでしょうか。
はい、そうです。
ローソン側も、このデータの位置精度は Survey で作っています。
なので、絶対位置としての情報は、僕達の位置とそんなにずれていない(はず)です。

また、インポートした後のデータを「やっぱ位置ちげーよ」と、Nodeを移動させるのはアリなのではないか、と思います。

>ikiyaさん
> ということはOSMデータ内に一般マッパーによる変更をよしとしないデータができてしまうと思います。
> OSM内のローソン データに触れる人は偏り、提供元にコントロールされるデータにならないでしょうか。
Nodeに対するデータの量は増えますが、一般マッパーによる変更が制限されるとまでは思えません。

たとえば、店舗のひらがな名称は、ローソン側データのほうで撥音表記に誤りがある場合が見つけられており、
OSM上でそこに対して行った修正をまたインポートデータで無理やり上書きすることはよくないと感じます。

ローソンという提供元を1つのコントリビュータとみると、
OSM上でのタグや位置の変更をよしとせずにオリジナル側のデータをまた上書きするのではなく、
むしろ、間違っている可能性がある箇所をOSMで変更し、
変更したデータの差分を還元して元データのブラッシュアップに役立ててもらうほうが健全かな、と感じます。

インポートによる自動更新を行うとした時に、どこまで自動的な上書きを行うかは、まだ未定です。
個人的な印象ですが、強制自動更新ではなく、自動的なチェックが中心にしたほうがよいのでは、と考えています。
(基本的に自動的な上書きをせずに、差分発生アラートだけをあげる。
lawson:idなどのタグを作っても、理論上では重複の可能性あるので、
Node Object IDしか一意のものは生成できないなぁ、とも思っています)

>【その２.】：精度の基準を知らせてください。
詳細な値はまだ確認中ですが、データはSurvey品質で作成されており、
ほとんどのデータは既存のOSMノードから数メートル程度の誤差になっている印象です。
(向日市の例があるので、全部が超精密な精度、とはとても言えませんが)


>【その３.】："いったん絶対精度にあわせませんか？"は唐突では？
そうですよねぇ。

いまのOSMの大部分(特に道路と建物)の大部分が相対位置の正確さに依拠している以上、
絶対位置の正確さが正しいものを投入してもあまり意味はない気はします。

どれだけあるかはわかりませんが、ローソン側の位置を採用することで
・道路の反対側に店舗が移動しちゃう
・Nodeが建物の外に飛び出しちゃう
などの事象は容易に考えられます。
それは、たとい絶対位置やタグ内容の鮮度が正しかろうが、
地図としての全体的な品質の低下を意味します。

これが、例えば基盤地図2500レベルの建物と道路がインポートされた後、など
絶対位置の正確さがそれなりに向上した状態でのインポートなら、
マージ時にローソン側データにあわせるほうが全体的な精度が向上すると思います。

ので、位置データは既存にあわせる、で＋1です。

あと、いままでOSMが幾多の失敗を重ねて作り上げてきた方針である、
インポートのガイドライン、「既存のデータを壊さないで」にも反します。
http://wiki.openstreetmap.org/wiki/JA:Import/Guidelines

確かにインポートデータの提供者もコントリビュータの1つではあります。
逆に言えば、彼らの権限と同じだけの権限も、既存コミュニティの1人1人が持つものと考えます。


あと、逆の発想ですが、もしローソン側データの店舗位置が
OSM既存データとあきらかに離れた場所にある場合、
その場所の近辺は Bing のオフセットが大きくずれている可能性が高い、とも言えます。
マージ作業中にそういう場所を見つけた場合、
なにかしらの手段で、別途注意喚起をしたほうがよいかな、とは思いました。


2013年9月12日 17:07 ikiya <insidekiwi555 ＠ yahoo.co.jp>:

> ikiyaです。
>
> ３点ほど。
>
> 【その１.】：既存データとのマージはほぼインポートデータの上書きで、今後は自動更新では
> ローソンデータに触れる人は偏るのではないでしょうか？
>
> >ローソンデータ・マージ手順書
> >既存のデータとインポート用のデータのマージ作業を行う際の手順について解説します。
> > ・
> > ・
> >■基本方針
> >・"既存データ"の編集履歴は可能な限り残す
> >・"ローソンデータ"と競合しない"既存データ"のタグは、残す
> >・"ローソンデータ"と競合する"既存データ"のタグは、"ローソンデータ"を採用する
> >・Nodeの位置 (緯度経度) は、"ローソン側"を採用する
> >・タグづけの競合が発生する場合、”ローソン側”を採用する
> > sourceタグは併記を行う
> >・以下の場合には、OSMの”ノート”機能を使い、コメントを残すようにする
> > (なお、JOSMのNoteプラグインを使うと、ノートの管理が楽です)
> > Nodeの位置が大幅に変わった場合
> > 既存データがAreaで、リレーション化した場合
>
> このマージ方法だと、
> 既存タグの内容とノードの位置座標ともにインポートデータ優先で上書きされます。
> さらにこのローソンデータは日々、インポート更新を計画されるとのこと、
> ということはOSMデータ内に一般マッパーによる変更をよしとしないデータができてしまうと思います。
> OSM内のローソン データに触れる人は偏り、提供元にコントロールされるデータにならないでしょうか。
>
>
> 【その２.】：精度の基準を知らせてください。
>
> 田中さんも触れられている精度の問題で
>
>
> >ただ、ローソンさんのデータですが、実はかなり私達の調査方法に近い手法で、
> >さらに細かい精度をだせるやり方でノードを置いています。
> >(詳しく話せなくてごめんなさい。もどかしいです)
> >これは、緯度経度による絶対精度のお話です。
> >もちろんOSM側はみなさん(特に都市部では)とても気を使って
> >周辺の建物の位置などと調整されていると思います。
> >OSMの建物は、常にずれている可能性があることを想起ください。
> >これは、周辺の地物との調和、つまり、相対的な精度のお話で す。
> >どちらを優先しましょう？というお話で、
> >いったん絶対精度に合わせませんか？という提案です。
> >ちなみにそもそもマージ用に検索を行う場合、
> >「重複している可能性あり」と判定するのは15mくらいの半径でヒットさせようと思っています。
> >つまり、最大で30mくらいのNode移動になる可能性があります。
> ># 基盤地図25000を使っているくらいの感覚でしょうか。
>
> と言われますが、
> >さらに細かい精度をだせるやり方でノードを置いています。
> のコメントだけでは、精度の論点がぼやけています。
> 精度については透明化してください。1/2500、1/25000なり。
>
> 最後に言われている
> "# 基盤地図25000を使っているくらいの感覚でしょうか。"
> が精度の例えだとしたら、
> 私のハンディGPSのほうが精度が良い場合は考えられます。
>
>
> 【その３.】："いったん絶対精度にあわせませんか？"は唐突では？
>
>
> >もちろんOSM側はみなさん(特に都市部では)とても気を使って
> >周辺の建物の位置などと調整されていると思います。
> >OSMの建物は、常にずれている可能性があることを想起ください。
> >これは、周辺の地物との調和、つまり、相対的な精度のお話です。
> >どちらを優先しましょう？というお話で、
> >いったん絶対精度に合わせませんか？という提案です。
>
> 先にも触れましたが、元データの絶対精度はどの程度なのでしょうか。
> また今まで、多くのユーザーがいろ んなソースをもとに
> 相対的な精度を考慮しながらマッピング書いてきた経過があるのに
> 唐突に絶対精度をかざされても、地図自体も、ユーザーも調和はとれないと思います。
>
>
>
>
> --- On *Thu, 2013/9/12, Toshihisa Tanaka <tosihisa ＠ netfort.gr.jp>* wrote:
>
>
>
> としです
>
> このインポートデータの位置精度は、GPSのDOP(HDOP)ではどれくらいでしょうか?
>
> また、絶対精度が良い場合、HDOPがさらに良ければその方を採用するという事ですね。
>
> つまり、インポートデータより私の自作ロガーの方が精度が良いならそれを採用するという事で良いでしょうか。
>
> 2013年9月12日木曜日 Satoshi IIDA nyampire ＠ gmail.com<http://mc/compose?to=nyampire@gmail.com>
> :
>
>
> いいだです。
>
> ローソンのインポートデータですが、マージの手順書を作ってみました。
> 特に方針部分、違和感を感じる方が多いと思いますので、ぜひぜひご意見をください。
>
>
> https://docs.google.com/document/d/1hsk4oBwnbtXSoQdqbwWkCsD5m4IYNgAEGr6J7HvMwCA/edit#
>
> ■問題になるところ
> ■1. 既存データがNodeで、ローソンデータがNodeの場合の位置情報
> 位置情報はローソン側のデータを採用したいと思っています。
> 「おいおい、調査で置いた情報が優先だろ？」というかた、たくさんいらっしゃると思います。
>
> ただ、ローソンさんのデータですが、実はかなり私達の調査方法に近い手法で、
> さらに細かい精度をだせるやり方でノードを置いています。
> (詳しく話せなくてごめんなさい。もどかしいです)
> これは、緯度経度による絶対精度のお話です。
>
> もちろんOSM側はみなさん(特に都市部では)とても気を使って
> 周辺の建物の位置などと調整されていると思います。
> OSMの建物は、常にずれている可能性があることを想起ください。
> これは、周辺の地物との調和、つまり、相対的な精度のお話です。
>
> どちらを優先しましょう？というお話で、
> いったん絶対精度に合わせませんか？という提案です。
>
> ちなみにそもそもマージ用に検索を行う場合、
> 「重複している可能性あり」と判定するのは15mくらいの半径でヒットさせようと思っています。
> つまり、最大で30mくらいのNode移動になる可能性があります。
> # 基盤地図25000を使っているくらいの感覚でしょうか。
>
> なお、既存のノードの編集履歴は保存するようにマージします。
>
> ■2. 既存データでAreaとして書いてあるコンビニ
> コンビニの情報をローソンデータのNodeに集約した上で、
> リレーションにまとめたいと思っています。
>
> 「OSM Wikiによれば、Areaとして描くことも許されているのでは？」というかた、たくさんいらっしゃると思います。
> はい、そのとおりです :)
>
> ただ、この方法で描く方法の利点は2つあります。
>
> 2-1. コンビニの廃業を考える
> コンビニが撤退することなどを考えると、
> コンビニの敷地をlanduse=retailとして表現し、別途コンビニのNodeを置くほうが
> 表現としてスッキリすると思っています。
> あくまでコンビニは、かなり一時的な店舗施設であり、その土地を持ち続けるわけではありません。
>
> (では同様の描き方を学校などにも行うの？という意見、あると思います。それは別の議論として、ここでは開店閉店のサイクルが早いコンビニに焦点を絞らせてください)
>
> 2-2. データとして扱う際の取り回しやすさ
> コンビニの店舗情報をNode側に持たせるか、
> それともRelation側に持たせるか、悩ましいところです。
> ただし、Node側に持たせることで、データを使う側として考えた時に扱いがしやすい、というメリットが有ります。
> 主にデータ利用者からして、「リレーションのことを考えなくて済む」「中心点を算出しやすい」というメリットが生まれます。
>
> また、type=siteリレーションは、広く利用されているとはいえ
> 情報の定義に不確定さを持っており、利用するにはちょっとはばかられます。
> (role定義がまともに決まっていない)
>
>
> 当然、テストをする段階で、悩む場面はさらに出てくるとは思います。
> ひとまずのたたき台として、どうでしょう？
>
>
> --
> Satoshi IIDA
> mail: nyampire ＠ gmail.com
> twitter: @nyampire
>
>
> _______________________________________________
> Talk-ja mailing list
> Talk-ja ＠ openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>


-- 
Satoshi IIDA
mail: nyampire ＠ gmail.com
twitter: @nyampire
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://lists.openstreetmap.org/pipermail/talk-ja/attachments/20130914/e03241d3/attachment.html>