Re: [OSM-ja] sourceタグの運用について (Was: fixme)
いいだ さん 英語ML その他肌感覚も含め いいださんの認識も詳しくありがとうございます。 私が他のマッパーさんの変更セットの情報をを見たり、 地物についてるソースを見たりしたときに感じた疑問点がほぼ網羅されているように思います。 また、英語のML等で話題が盛り上がり、ソースへの記述を減らそうという動きがありましたら 追従したいと思います。 で、自分はソース今後どう書いていこうかな…という結論は出ませんが 作業する地域、タイミング、ソース同士の重要度の差などによって、柔軟にやっていきたいと思います。 引き続き異なった見解をお持ちの方などおられましたらご意見いただければと思います。 centree - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: Muarkami Oki oki_aic...@yahoo.co.jp; OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/5/22, Fri 22:53 Subject: [OSM-ja] sourceタグの運用について (Was: fixme) いいだです。 スレッドを改めました（失敗してたらごめんなさい） sourceタグの運用について（インポートに限らず）ですが、 改めて sourceタグの wikiページを読み直しました。 すみません、「必ず書き換える」という感じではないですね。 列挙する形式でも、書き換えでも、どちらでもよいようです。 http://wiki.openstreetmap.org/wiki/Key:source http://wiki.openstreetmap.org/wiki/JA:Key:source 「使用方法 (How to use)」の項目です。 ただ、英語MLを読んでいて、僕の肌感覚の部分も混ざってしまうのですが、 以下の部分の感覚が違っているのだと感じています。 * そもそも sourceタグは、CC-BYなどの出典明示要請に対する完全な対応方法とはなり得ない * sourceタグはあくまで、「他マッパーに対する、オブジェクトの情報正確性の度合いの伝達手段」である * sourceとして利用した情報元のデータは、変更セットへのsourceタグ付与で行う方法も可能である。 これによって、データベース全体として容量削減が可能となる。 * なおかつ、オブジェクトに対して紐づく変更セットの履歴は、永久に不変な状態で残るため、個々の編集における正確性の変動は、オブジェクトの履歴を逐一投入することを容易にし、それを手がかりにして情報を追うほうが、より正確に状況を辿ることができる * オブジェクトに対するタグ付けよりも、変更セットに都度付与された情報を追うことにより、どの情報が、どの変更セットで、どの情報を元に変更されたのか、を追跡するには、変更セットをもとにしたほうが参照しやすい、あるいは十分ではないか？という考えがある (飯田私見: ここに大きく異論はあると思います。ただ、今後、バージョンが20や30になったオブジェクトのことを考えると、合理的であるとも感じています) * CC-BYなどのデータをインポートする場合に要求される「出典明示」は基本的に、「変更セットへのsourceタグ付与」で行う (飯田推測: これは主に、OSMデータベース全体としての容量の圧縮のため) * ただし、データインポートの出典明示を行う場合においてすら、変更セットへの表記を間違ってしまうこともある。 * そのため、インポートにあたっては専用アカウントを作成し、さらにOSM wikiおよびOSM.orgの著作権解説ページにおいて、利用する情報の詳細を解説することを強く推奨する。これにより、その編集アカウントに紐づくデータの由来に対する追跡可能性をできる限り高めるようにしている。 * iDエディタは初心者ユーザによる利用が圧倒的多数である。 * そのため、オブジェクトあるいは変更セットへの正確な記入は、漏れが多くなる、という判断がある。 * その対応として、 imagery_used タグを変更セットに自動付与することにより、追跡不可となる可能性を低減している。 * (飯田認識) なお上記は、OSMF本家などでの会議の末の 決定事項 ではない。 なお、インポートにおいて、オブジェクトへの sourceタグが許諾され、行われている例もあると認識しています。 ただしその場合は、「クエリなどで調査を行うため、○○のようにつかう」のように、用途が明確に利用されていたりする場合、と認識しています。 （エボラ熱の対応におけるインポートなど） それから、国土地理院やYahoo/ALPSデータの利用運用についてです。 Yahoo/ALPSとの過去の情報を追ってみましたが、出展明示方法を含め、運用については特に定める記載が無いようです。 当時はデータを利用するに際して、OSM側での運用にもとづいて、オブジェクトへのsourceタグ付与、という形でインポートが行われたという認識です。 （当時は変更セットへのsourceタグ付与という概念が無かった） 国土地理院 (地理院地図、基盤地図情報) や、国交省 (国土数値情報・位置参照情報) の利用については、出典明示が要請されています。 ただ、その明示方法についてはOSM側に任されています。 また、出典明示における現在の運用がどのようになっているか (オブジェクトあるいは変更セットへのタグ付与) は、説明を実施しており、ご理解をいただいているという認識です。 以上、僕の認識が間違っている可能性も大きいかと思います。 ご意見いただければ幸いです。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] fixme (Re: KSJ2バス停データインポートについて(Was: Geodata Platform))
いいださん、みなさん 新たにスレッド立てるべきなのかもしれませんが… 現在のsourceタグの運用としては、 ・変更を行った場合、sourceタグへ 追記 ではなく、 書き換え を行う というのが正式な手順だと認識しています。 つまり、source = KSJ2; survey のように列挙はせず、書き換えるということです。 これは、すべてのタグについてそのような流れ、と認識してもよいのでしょうか。 作業していて 建物=Bing、建物名＝survey 道路名、国道県道名称＝Yahoo/ALPS、ウェイ＝GSImaps/stdで修正 ということもあり、今のところ（安全を期して？） source:name= のようなもので分かち書きするのではなく 単純に source:Bing; survey のように列記しています。（後ろにいくほど新しい） 書き換えで元のソースが表面上消えてしまうのを気にしているんですが JOSMだと履歴で情報自体はたどれそうなので、全く消えてしまうという心配はなさそうですよね。 他のエディタだとどうなんでしょうか。 あとは、タイル/レイヤーの提供元との最初の合意条項と “sourceの書き換え”（上書き）の整合性が取れるようであれば、 …作業的には“書き換え”のほうが楽ですし、サーバに置かれるデータのスリム化にも貢献できますよね… なんかドキュメントとかソースがあると安心かなと思いますが 世界的な観点と、あと主に国土地理院やYahoo/ALPSなどOSMFJが交渉にあたった時の 認識などを踏まえて、何か付加的な情報をお持ちでしたらシェアしていただければと思います。 centree - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/5/19, Tue 18:31 Subject: Re: [OSM-ja] fixme (Re: KSJ2バス停データインポートについて(Was: Geodata Platform)) いいだです。 生還おめでとうございます (^^;) fixme tag これの一番の問題は「付与されたまま放置されること」にあると思っています。 なので、「ちゃんと用途があって、使います」「今後の更新の際に、消すようなフローにします」ということが明示できればよいのじゃないかと思います。 ただそれでも、 (繰り返しになってすみません) imports MLで強い抵抗があると思っています。 OSMAndを使ってfixmeを表示できる機能も追加されて 以前よりはフローが回しやすいかもしれませんので、説得の材料には使えるかも？ http://www.openstreetmap.org/user/stephan75/diary/34954 （設定ペインを開いて、画面右上の 三 をタップ、 マップ設定→詳細の追加描写→OSMマップ作成アシスタントをON） また、fixmeを使わない場合（僕はこっちのほうがよいと思っています）ですが、 もしオブジェクトに対して sourceタグに KSJ2/P11 2012 を付与するのであれば、 fixmeがなくともそれで判別できそうな気がします。 現在のsourceタグの運用としては、 ・変更を行った場合、sourceタグへ 追記 ではなく、 書き換え を行う というのが正式な手順だと認識しています。 つまり、source = KSJ2; survey のように列挙はせず、書き換えるということです。 なので、KSJ2由来のバス停をsurveyした場合、sourceタグの書き換えが行われ、 source=surveyに書き換えられる （あるいは、オブジェクトへのsourceタグが消され、変更セットへのsourceタグ付与で書き換えられる）というフローになるのかな、と思っています。 http://wiki.openstreetmap.org/wiki/JA:Key:source それであれば、オブジェクトに対してsourceタグを付与する理由にもなると考えています。 (基本的に、インポートのオブジェクトにsourceタグを入れることも、あまり推奨はされないという認識です) -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] Clean-up?: KSJ2 administrative boundary import
centree（むらかみ）です。 (2) A島がX市に属し、B島がY市に属するなら、その中間辺りにX市とY市の 境がある、というのが自然な感覚です。 感覚としては同意見です。 ただ「感覚」ですといろいろと異論（攻撃的なのはナンセンスですが…）も出るでしょうから、 ある程度異論をおっしゃられるマッパーさんたちに納得のゆくソースを 示せればよいのかなと思っています。 個人的には、海上の境界は今のところ国土地理院タイルくらいしか参照できる ソースがないのかなぁ〜と思っているのですが、その頼みの地理院タイルにしても 海上の市町村境界は描かれていない部分がかなり多く、 リレーションとして閉じるには情報が不足しているのかな…と思っています。 いいださんもおっしゃられてたかもしれませんが、国土地理院タイル以外に 良いソースがあればMLでも紹介していただきたいですし、 チェンジセットなどにソースを明記されるのも良いと思います。 (4) 海岸線の編集が難しく、編集ミスのリスクが高いです。海岸線と行政境界が ほとんど同じ座標の点で引かれているため、海岸線を選択することが難しく、 新たに海岸線を追加するときも、元からある海岸線と接続することが難しいです。 海岸線が閉じられない編集ミスをしてしまうと大規模に陸地が表示されなくなる プレッシャーがあり、本来は衛星写真やサーベイ情報などで海岸線を修正したくても、 行政境界がまとわりついている場合は編集を敬遠してしまいます。 南伊勢町のように、海岸線と境界を同じウェイにするとしても、海岸線を編集したい 場合は行政境界のタグやリレーションの整合を毎回考慮、確認する負担を強いられます。 わたし個人として、自分が編集していた地域の行政境界が海岸→海上に移行していたので、 海岸線を編集（修正）しやすかった、という経験はあります。 でも、それだから海岸は行政境界とせず、海上を行政境界とした方がいい、 という結論をしてしまうのは早い気もします。 すでにご認識のように、海岸線に境界の機能を付与することもできるでしょうし… 私のように海に近い地域で生活している者には、海上に行政境界があると 便利な点があるのも事実ですが、陸地側に境界があった方が使いやすいという方も いらっしゃるでしょうし… いずれにしろ、ikiyaさんもおっしゃられているように このMLに限りませんが、cleancoastjapanさんたちのご意見に触れる機会、 意見を交換しあえる場所があればうれしく思います。 centree（むらかみ） - Original Message - From: cleancoastja...@yahoo.co.jp cleancoastja...@yahoo.co.jp To: talk-ja@openstreetmap.org talk-ja@openstreetmap.org Cc: Date: 2015/3/1, Sun 09:04 Subject: [OSM-ja] Clean-up?: KSJ2 administrative boundary import はじめまして。 ちょうど私どもが頭を悩ませている問題について、このMLで投稿されていると聞き、 急いでMLに登録しました。保存書庫を参照してメールしますので、 スレッドがつながらないかと思いますが、ご容赦ください。 また、行政境界や海岸線を編集していると「編集を止めろ」というメールを 受け取ることがあるという情報もあり、OSM上でのアカウントや具体的な活動地域を 伏せて投稿しますこと、失礼をお許しください。 さて、海岸線に沿った行政境界についてですが、地図の利用者として、また 地域貢献をしようとするマッパーとしての立場では、この行政境界には 非常に困っています。 (1) 地図の利用者から見て、欲しい情報が得られません。島などの海岸線が 込み合っている地域では、すべての海岸線が境界線と重なって表示されるため、 結局のところ、例えばある市に属するのがどの辺りまでなのか把握できません。 例えばですが、 http://www.openstreetmap.org/#map=12/34.7133/134.5132 のような地図を見て、兵庫県の沖の島々が何市に属するか、分かるでしょうか。 (2) 海岸線に市や県の境界があるという表示は、地域の生活者の感覚からは かけ離れています。海岸から少しでも沖に出ると県外、という感覚はありません。 A島がX市に属し、B島がY市に属するなら、その中間辺りにX市とY市の 境がある、というのが自然な感覚です。また、A島とB島の間に橋がかかっていれば、 橋がX市にもY市にも属していないことはありえず、橋のどこかに境が あるはずです。 (3) 境界線のデータが複雑すぎてデータが異様に重くなり、編集や確認が 困難になっています。 例えば、三重県のリレーション http://www.openstreetmap.org/relation/812190 は、皆さんの環境では正常に表示できるでしょうか。私の環境では「リレーションの データは大きすぎるため表示できません」と表示されブラウザが固まります。 OSM Relation Analyzerでも、 http://ra.osmsurround.org/analyzeRelation?relationId=812190 はタイムアウトします。 今はきれいになっていますが、長崎県のように海岸線が複雑な地域でのデータの 重さはひどいもので、市くらいの単位でもリレーションの表示や確認ができませんでした。 (4) 海岸線の編集が難しく、編集ミスのリスクが高いです。海岸線と行政境界が ほとんど同じ座標の点で引かれているため、海岸線を選択することが難しく、 新たに海岸線を追加するときも、元からある海岸線と接続することが難しいです。 海岸線が閉じられない編集ミスをしてしまうと大規模に陸地が表示されなくなる プレッシャーがあり、本来は衛星写真やサーベイ情報などで海岸線を修正したくても、 行政境界がまとわりついている場合は編集を敬遠してしまいます。 南伊勢町のように、海岸線と境界を同じウェイにするとしても、海岸線を編集したい 場合は行政境界のタグやリレーションの整合を毎回考慮、確認する負担を強いられます。 以上のように、地域で使いやすい地図に貢献したい私どもとしては、機械的、一律的に 海岸線に引かれている行政境界には頭を悩ませています。OSMの初期でまともな情報が 無い段階では、外部の利用できるデータを機械的にインポートする意義もあったかと 思いますが、これだけ全国に編集者が増え、各地域での情報に基づいたデータが 蓄積されつつある段階で、境界の変更が無い地域も含めて一律にインポートをし直す 必要性があるのでしょうか。(その割にはデータがインポートされていないらしい 群馬、栃木などの関東を「後回し」にする意図も不思議ですが) このMLの過去メールを追いきれず、同じような議論が繰り返されているかも知れませんが、 地域目線でOSMに貢献しようと活動している編集者や、純粋に地図として使おうとする 利用者の視点も、ぜひご考慮ください。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] fixme (Re: KSJ2バス停データインポートについて(Was: Geodata Platform))
centree（むらかみ）です。 ただし、インポートによってこのタグを付与するのは避けよう、という状況です。 なぜなのでしょう？ それに削除が提案されていても、そう決定したわけじゃないのですよね？ wikiページにそれらしき表現を見つけました。 http://wiki.openstreetmap.org/wiki/JA:Key:fixme （「ロボットや自動編集のためのタグではありません」の段落） マッピング寄りの貢献者ではなく、システム開発（管理？）寄りの貢献者の方からすれば、 データが少ないほうがサーバに負担がかからない（と自分では思ってます…）ことから、 重複するようなタグは削減したいという、大きな流れがあるのかなぁと思います。私はImports MLを購読してないのではっきりとはいえませんが… いずれにしても、日本語のwikiページなどに最新の情報、手順等が わかりやすくまとめられれば疑問やある種の誤解も減るのかなと思いますが、 翻訳やまとめは人力ですので、スピードや作業量の限界があるのも事実だと思います。 どうやって最新の情報を集めたら良いのだろうか、と考えながら、 とりあえずOSM-jaを購読して勉強させてもらっています。 不慣れな点や不確実な情報がありましたらご容赦ください。 centree（むらかみ） - Original Message - From: InagakiM kgg00...@nifty.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Cc: Date: 2015/3/8, Sun 13:10 Subject: Re: [OSM-ja] fixme (Re: KSJ2バス停データインポートについて(Was: Geodata Platform)) 稲垣＠八王子です。 On Sat, 7 Mar 2015 23:46:25 +0900, Satoshi IIDA wrote: これまでのインポートによって付与された fixmeのみを削除することになっています。 日常的にマッパーによって付与されている fixmeはメカニカルエディットの対象外であり、残ります。 もちろん、あとから付加した fixme が対象外なのは（最初から）理解し ています。そう書いたつもりだったのですが、ああ、すみません、書き方を 間違えました。正しくは―― これはバス停に限らない、『すべてのインポートされた』 fixme=xxx の 話ですよね？ ――と書くべきでした。 ただし、インポートによってこのタグを付与するのは避けよう、という状況です。 なぜなのでしょう？ それに削除が提案されていても、そう決定したわけじゃないのですよね？ ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] place=quarterタグの現状と今後について
centree です。 https://github.com/gravitystorm/openstreetmap-carto/issues/798 OSM標準タイルにplace=quarterをレンダリングしてほしい！ という個人的な希望を書いてみました。 微妙に説明間違ってるかもしれません、その時は援護（擁護？）いただければ幸いです。 また良い進展がありましたら報告します。 centree（むらかみ） - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: Muarkami Oki oki_aic...@yahoo.co.jp; OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/2/27, Fri 18:14 Subject: Re: [OSM-ja] place=quarterタグの現状と今後について いいだです。 個人としてgithubのフォーラムに 投稿すること 誰もが個人として書き込んでいますし、 すべての経緯を説明するのではなく、現状と予定を伝えるだけでも十分だと思います。 boroughもレンダリングしてほしい、という要望もあるようですし、 書き込んでみてはどうでしょう？ (最初の投稿者の math1985さんはよく日本のことをご存知のかたですし、 うまくフォローしてくれると思いますよ :) ) 2015年2月27日 11:38 Muarkami Oki oki_aic...@yahoo.co.jp: 以前、quarterタグが標準タイルで表示されない件について質問させていただいた centree（むらかみ）です。 （https://www.mail-archive.com/talk-ja%40openstreetmap.org/msg08310.html） あのあと、OSM標準タイルにおいて、place=quarter はそのうちレンダリングされるだろうと 甘い期待を持っていたのですが、現状ではレンダリング要望はrejectされているみたいです。 https://github.com/gravitystorm/openstreetmap-carto/issues/798 なんとなく英語を読んでみると、reject後も熱い論議が提起されているみたいですが quarterタグを今後多く利用して行こうという流れになっている日本ユーザーからも良いタイミングで 要望が必要なのかなと思っていたりします。 ※過去の議論では、OSM標準タイルに、日本独特のレンダリングを望むのは難しく osm.jpに日本独特のレンダリングルールを盛り込むという方法で結論に至ったこともあったようなのですが、 PotlatchやiDがユーザーのこと（編集した後にわざわざosm.jpを見に行くとは考えにくい）また、 br osm.orgにいろんな機能が組み込まれるようになったことも考えると、標準タイルでのレンダリングのことも 考えておく必要があるのかなと個人的には思っています。 それで、要望の方法とタイミングなんですが、皆さんどのようにお考えでしょうか？ quarterタグを徐々に増やしていって、日本での重要性と実績を元に要望を出すと通りやすいのかなと思いますが ・OSM標準タイルに表示されないのに、タグを増やすという作業へのモチベーションの問題 ・ISJからのインポート／基盤地図からの目視トレースなど、使える元データはあるが 日本での合意事項に従って活用しようとすると、正しくquarter / neigbourhood に分類、分かち書きできるか subareaを使ってのリレーションをうまく組めるか、など懸案事項も多いように思えます。 https://docs.google.com/spreadsheets/d/1eAE72mjCLoJVGZo5qRhCYK22UxVQ8bpbQSU9ZLHq40o/edit#gid=0 http://qiita.com/nyampire/items/423344fa75707dc138af http://wiki.openstreetmap.org/wiki/JA:MLIT_ISJ_CHOME そうすると、まずはquarterタグを増やす前に、日本での必要性を訴えて osm標準タイルでレンダリングしてもらえるよう要望を出しつつ、 quarterタグに何を入れるべきか、リレーションをどうするか、インポートをどうするかといった議論を並行して行ない 合意を形成した方が良いのかもしれません。 いいだしっぺの私ですが、上記のことで、私がお手伝いできそうなことは 個人としてgithubのフォーラムに 投稿することぐらいですが、 日本のMLでの歴史も踏まえてということになると英語での作文ということもあり自信がありません。 あまり出来ることがなくて恐縮なのですが、何かいいアイデアや、 上記のことに関してすでに行われている動きなどありましたら知識として共有させていただければと思います。 ※個人的には、自分の活動エリアに関して、標準タイルでもレンダリングされる neighbourhood やhamlet でタグ付けしたい誘惑に駆られています…というか 一部、neighbourhood でタグ付けしたものも残してしまっています… いけませんね、そのうち正しいものにしたいと思います…（汗） よろしくお願いします。 centree(むらかみ） ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] インポートデータに関する削除について
centreeです。 タスクマネージャ、先走って#1-#3までやってしまいましたが… 幸いなことに、削除（候補）のデータはおろか、building=yesのデータも見つからない地域でした。 （わざと難しくなさそうな地域を狙ったのもありますが） いったん論議がまとまるまで作業を止めておきます。 ikiyaさんがおっしゃるように、確かに国土地理院の標準タイルとの比較では、 インポートかそうでないのか判断に迷うこともありますね…。 それで、ikiyaさんのおっしゃられるような、より丁寧な手順を踏むなら、 インポートではない貴重な情報を誤って消してしまうような危険は最小限に抑えられると思います。 反面、インポートデータの削除スピードは格段に落ちてしまいますので ODbLライセンスに反するデータを含む情報が（望まずとも）公開され続けてしまい こちらは、場合によっては対外的にも影響が出る可能性もあり、あまり望ましい状態とはいえないと思います。 当事者の編集権重視か、ODbLとの整合性重視か、それぞれ意見の分かれるところだと思いますが ikiyaさんの案（タスクマネージャ―でまず情報収集） + 適度な期限の設定（期限が過ぎた場合の対応も決めておく）を すると、うまくいくような気もします…が、どうでしょう…？ ikiyaさん 基盤地図情報をそのものを背景にして見る もし上記活動が本格化しましたら、よければ方法を教えてください… （すみません、初心者なのでタイルを背景にすることしかしらないもので…） いいださん user:mitsurukikkawa user:徳島県オープンデータ に加え user:kikkawamitsuru もインポートに使われているような気もしますが…勘違いだったらごめんなさい。 centree(むらかみ） - Original Message - From: ikiya insidekiwi...@yahoo.co.jp To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/2/27, Fri 23:09 Subject: Re: [OSM-ja] インポートデータに関する削除について ikiyaです。 徳島県のインポートデータについてですが、 タスクマネージャーを使うのは賛成ですが、 削除にはもうワンステップ置いてもようかと思います。 まず、タクスマネージャーを使って、明らかに基盤地図情報以外のソースで書かれていることが確認できたエリヤ（OKですよエリヤ）を増やしていく作業を進めればよいと思います。 その結果、インポートデータが残っていそうなエリアが絞りだされるので、当事者とさらに話し合いや削除を依頼するなりの手立てができるかと思います。 さらにJOSM上で地理院地図の標 準タイルと重ねて比較しても、 地理院タイルの解像度の低さや、地理院タイルのレンダリングと基盤地図情報の建築物外周線との違いから JOSM上での判断には難しい面もあります。 JOSMで比較してみるなら、基盤地図情報をそのものを背景にして見る（チェックする）ことがベストと思います。 JOSMでのチェックですが見てみると この周辺はまだ建物に２重ノードが大量に残っています。 http://www.openstreetmap.org/#map=18/34.17339/134.62052 このような場所を手分けして確認しあう作業がよろしいのではないでしょうか。 - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2015/2/27, Fri 21:28 Subject: Re: [OSM-ja] インポートデータに関する削除について いいだです。 和歌山県のデータについて、削除作業が完了しました。 ユーザ1029さんによるインポート建物オブジェクトが残っていないことを、OverPass turboで確認を行っています。 次は徳島県のデータの削除なのですが、 こちら、現在の状況を確認したところ、 ひとりで対応するのはかなり難しい状況でした。。。 「私がやる」といっておいて申し訳ないのですが、 以下にタスクとして登録しましたので、みなさま、ご協力をいただけないでしょうか。 http://nyampire.info/project/6 また、徳島県オープンデータ と mitsurukikkawaのアカウントでは、 すみません、引き続き、建物データの編集を実施しないようお願いします。 ``` 上記タスクの手順でも、ユーザによるフィルタをもとに対象となるデータの絞り込みを行います。 そのため、データが削除されているならよいのですが、編集、をされてしまうと、 その建物データが削除対象のデータかどうか、すべて目視でチェックしないといけなくなります。 なるべく早い作業完了のため、何卒ご協力ください。 ``` Tasking Managerの使い方に不安のある方は、 まず最初に海上のなにもオブジェクトがないエリアを選択し、何度かお試し作業をしてみてください。 ■検討事項 インポートによって追加された建物データに対して、 amenity=place_of_worship などのデータが付与されているものが散見されます。 こうしたデータは、新しくノードかエリアのオブジェクトを作成し、 そこにタグを移植して、インポートデータのオブジェクトを削除するのがよいのかな、と思っています。 ただし、正直言って、かなり手間になります。。。 いったんすべて削除をしてしまうのもひとつの手ではありますが、 過去に行われたKSJ2データ(公共施設)とのマージも行われているようで、 すべて削除した場合にはデータのロスがかなり大きいとも思っています。 ご意見いただけると嬉しいです。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 基盤地図情報のインポートについて
むらかみ（centree) です。 マッパー暦も浅く、地理院データの取り扱いについてもおおよそ素人なので恐縮ですが 個人的な意見を述べさせていただきます。 すでに幾人かの方がコメントしておられますが、 （書いている間にも多くの方がコメントされていて議論はかなりつまってきているとも感じますが…） やはりインポートしたデータはあとでいくら目視で手加工、手修正したとしても、削除対象 とすべきなのかなと思います。 OSMJと国土地理院の合意事項は、いわゆる第3者から疑義をかけられても釈明できるような、 幾ばかりかの安全余裕を見ての合意事項のように思われます。 今回のケースのように、インポートしたデータを参考にしていると公言された場合においては 特に国土地理院さん側が何も言わない場合であったとしても、 第3者から『測量法に則って許諾を得ているのか』という指摘を受けることも想定されますし、 『そうではない』ことを第3者に分かっていただくために費やす労力の問題もあります。 そういうリスクの回避と、国土地理院との良好な関係の維持などを考えると 疑われる余地のあるものは、貢献度とデータの量を考えると残念ですが、削除してしまうか 、 疑われないためのそれ相応の理由付けが必要と思います。 一つ前の投稿で どの地域においても、インポートのみはなく、トレースを行っております。 とおっしゃっていたのと思うのですが、 http://www.openstreetmap.org/#map=19/33.59226/134.35871 この辺の区域は建物のポリゴンに特徴があり インポートデータのようにも見えてしまうのですが、トレースも行なっておられますか？ また、作業IDは別ですが https://www.openstreetmap.org/#map=19/34.05012/134.58325 では複数の建物に 縦方向・横方向に規則的な分割線が現れています。 これは通常のタイルからのトレースによっては現れないように思うので、こちら付近も インポートデータに手が加わっていないのではないかなと想定されます。 （間違っていたら申し訳ありません…） インポートされた生デー タがもしそのままアップロードされているとしたら こちらは議論の余地なく、削除対象となると思います。 時代の流れ速いので、やがては国土地理院の方向性も変わって、このようなことで議論が起こっていたことが 笑い話になるときもくるかもしれませんが、現状ではもったいないですが削除して、疑いのより少ない方法で データ再作成が安全と思われます。 かくいう私もマッピングの際はいろんなことが抜けてしまうのでたいそうなことはいえないのですが、 ・手間ではあるが各リレーションごとにソースをつける、または付け加える ・マッピング直前に某大手地図会社の地図を見てしまったときは （不用意にそちらで見た情報がOSMに反映されないよう）普段以上に気を使う ・不明な点があれば（ある程度まとめた上で）MLで質問 など努力しています…。 もし、データ再作成が必要になったときは、たいしたことはできませんが、何かの形で助けになれればとおもいます。 --- むらかみ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] island タグの付け方の提案 及び 広域合併した町村名のタグ付けについて
いいだ さん 早速のコメントありがとうございます。 1.islandタグについて 知識不足でしたのに、意図を拾って頂いて感謝します… “リレーション”の種類のひとつに“マルチポリゴン”があるということだったんですね… いずれの方法も、良い面があるような気がします。 リレーションそのものにnameタグを貼った場合、有無を言わせずリレーションの中心に配置されると思うので 中心をずらしたいという場合にはよいのかもしれません…（自信ありませんが…） 勉強しながら今後のMLを見守りたいと思います。 2.広域合併した町村名のタグ付けについて すでにMLで議論されていたもの…ですよね…調査不足ですみません。 OSMのデータは、Mapnikだけに用意されたものではないですよね。 実は、タグ付けの疑問が生じた時、文章で書かれたタグ付けのページをあまり深く調べずに すでに多くのタグ付けがなされている地域のデータをJOSMで見て参考にしていました。 やはり（とくにある程度重要な部分のタグ付けをするときは）タグ付けルールをまとめたページに 立ち返って、最新の情報にも通じないと 思いました。 こちらも少しずつ勉強してみます。 コメントいただいて、再度ネットで検索して出てきた２つのページが役立ちました。 OpenStreetMapリレーションとは http://qiita.com/nyampire/items/13f6dd0daad5cc072ea8 日本のOpenStreetMap行政区リレーションについて http://qiita.com/nyampire/items/423344fa75707dc138af と思ったら、いいだ さんが書かれた記事でしたね… 助かります。ありがとうございます。 ※最後にまた初歩的な質問で申し訳ないのですが Talk-ja 過去全ての記事を縦覧検索する方法はあるんでしょうか。 ちょっとこちらでは見つけられなくて…もしよかったらご存知の方、教えて下さい。 centree (Oki M) - Original Message - From: Satoshi IIDA nyamp...@gmail.com To: Muarkami Oki oki_aic...@yahoo.co.jp; OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2014/12/19, Fri 00:16 Subject: Re: [OSM-ja] island タグの付け方の提案 及び 広域合併した町村名のタグ付けについて いいだです。 えっと、まず原則として、 Mapnikで表示させるためのマッピング手法を行うのはやめよう、 という前提がまずあるとして :) 1.islandタグについて 海岸線ウェイを使ってマルチポリゴン化、方針としては賛成です。 もうひとつの案として、 海岸線ウェイを使ってマルチポリゴン化し、 さらにplace=islandのノードを、 labelメンバーとして配置、というかんじではどうかな、とも思っています。 ただ僕のこの案をやると、リレーションとplaceノードという、 1つの対象に対する2つの地物ができてしまうことになるので、 困ったなぁ、とも思っています。 centreeさんの提案するように、 エリアとして描く時と同様、リレーションを作ったならば、 placeノードは不要、のほうが筋がよさそうです。 また、osm.orgのMapnik定義を行っている openstreetmap-cartoを紐解いてみましたが、 way_pixelsという値 (SQLでいうと、way_area/(!pixel_width!*!pixel_height!) AS way_pixels で抽出 なので、おおむね、ウェイの長さかな)によって、 表示のズームレベルを少し変えているように見えます。 https://github.com/gravitystorm/openstreetmap-carto 2.広域合併した町村名のタグ付けについて 論点がいくつかあるようなのですが、ざっくりこんなかんじでしょうか。 1. place=quarterが表示されない 2. place=neighbourhoodの表示はもっと広域でも行われたほうがよい →対策として、より広域でも表示探されるtownやsuburbをタグづけするのはどうか すみません、こちらは反対です。 あげていただいたJapan Taggingのページからもリンクがありますが、 place等のタグは階層構造を持っています。 その構造を崩して配置することによって、検索などにも影響が出てしまい、 逆に言えば、Mapnik表示以外の目的で OSMデータを使うことが難しくなってしまいます。 https://docs.google.com/spreadsheets/d/1eAE72mjCLoJVGZo5qRhCYK22UxVQ8bpbQSU9ZLHq40o/edit#gid=0 また、現在、市町村配下の町名がplace=townで 配置されている例がいくつかあることは認識しています。 (東京都の西側のほうなど) こちらはタグ付けの間違いだと思っており、 折を見て修正をかけようと思っているところです。 認識している限り、上記の階層構造が確定する前にマッピングされていた地物のはずです。 それから、より日本の状況にあった表示は、 osm.jpのタイルで試験運用を行っています。 https://openstreetmap.jp/map#zoom=12lat=35.66092lon=139.72309layers=B00 また、quarterが表示されない、など osm.org本家のMapnikに関するIssueは、 ごめんなさい、英語になってしまうのですが、 GithubにIssueをあげることで議論が可能です。 かなり頻繁にアップデートがされているので、 こちらをもとに本家へ修正提案したほうがよいかもしれません。 https://github.com/gravitystorm/openstreetmap-carto/issues -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 2012/9/12 ライセンス切り替えが行われました(Re: 次のplanetファイルよりODbLが適用されます)
ODbLのライセンスの全体像をまだつかみかねているのですが、少し質問させてください。 (1)特にOpensStreetMapsのオフラインでの利用に関してです。 (a)会社や個人宅のアクセスマップ(b)配送ルートマップ、顧客管理マップ(c)観光案内マップ等のベース（下絵）として、osmデータをsvgデータやaiデータに変換したものを使用し、(a)(b)(c)等のマップに独自情報を追加（ルートになる道路に矢印を設置したり、顧客の名前を記したり）して独自地図を作成（X）、Xを紙媒体に印刷する、画像やPDFとして書き出して配布するといった風に利用したいことがあると思います。 CC-BY-SAライセンスの場合は、このように作った独自地図Xにもライセンスが及ぶ（継承される）ように認識しているのですが、今度の新ODbLの場合はXのような成果物の場合、どのようなライセンスを適用するかは成果物Xの作成者にゆだねられる（ODbLライセンスを継承する必要はない）ということでしょうか。 (2)(a)(b)(c)のような地図を作成した場合に追加した独自情報をosmデータに反映するか否かは、ODbLライセンス上は任意であると考えてよいのでしょうか。（例：osmデータを元に配達ルートの矢印や顧客の個人情報などを加えた地図を作成した場合、その矢印の情報や顧客の個人情報は、osmデータに反映させなくてもODbLライセンスに反しないということでしょうか。←もちろん個人情報は公に開示すること自体に問題があると思いますが…） ※もしもともとosmデータに含まれていた情報（道路や店舗情報）の間違いに気づき、自分が作成した地図でそれを訂正する場合には、osmデータベースにもそれを還元するのが適当だとは思っています。 http://www.slideshare.net/higa4/20120729-odbl http://wiki.openstreetmap.org/wiki/JA:ODbL/We_Are_Changing_The_License http://wiki.openstreetmap.org/wiki/JA:Open_Data_License/Use_Cases このあたりも読んではみたのですが、なにぶんこのコミュニティでの経験が少ないもので、長年取り組んでおられる方の意見をお聞かせ願えればと思った次第です。 自分が理解しがたいと思った点は、どこまでがデータベースでどこからがマップタイルや芸術的な地図となる（？）のかといった点です。 調査不足の部分もあるかと思いますが、知恵をお貸しいただければ幸いです。 --- On Wed, 2012/9/12, Shu Higashi s_hig...@mua.biglobe.ne.jp wrote: 2012/9/12をもってODbLへのライセンス切り替えが行われました。 以後、OSMよりダウンロードした地理データはODbLの下に ライセンスされることになります。 http://www.openstreetmap.org/copyright http://wiki.openstreetmap.org/wiki/JA:Legal_FAQ http://wiki.openstreetmap.org/wiki/JA:ODbL/License_Transition/Guidance_To_Data_Consumers 東 2012/09/12 Shu Higashi s_hig...@mua.biglobe.ne.jp: 次のアナウンスがありました。 UST本日9/12水曜日よりODbLのplanetファイル作成が始まります。 詳細は下記を参照ください。 http://blog.osmfoundation.org/2012/09/12/%E3%81%84%E3%82%88%E3%81%84%E3%82%88odbl%E3%81%B8%E3%81%AE%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E3%81%A7%E3%81%99/?lang=ja 東 2012/09/06 Shu Higashi s_hig...@mua.biglobe.ne.jp: 本日のSotM2012Tokyoにて、冒頭、表記のアナウンスがありました。 http://blog.openstreetmap.org/ 詳細な記事は明日投稿されるそうです。 取り急ぎお知らせまで。 東 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] それはgmailの仕様です
ribbon さん ご指摘ありがとうございました。 自分が調べた範囲内ではGmailで受信できそうにないので、メールアドレスを変えてみました。 うまく受信できるとよいのですが… またアドバイスがあれば教えてください。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
