JA:インポート/ガイドライン

From OpenStreetMap Wiki
Jump to: navigation, search
利用できる言語 — Import/Guidelines
· Afrikaans · Alemannisch · aragonés · asturianu · azərbaycanca · Bahasa Indonesia · Bahasa Melayu · Bân-lâm-gú · Basa Jawa · Basa Sunda · Baso Minangkabau · bosanski · brezhoneg · català · čeština · corsu · dansk · Deutsch · eesti · English · español · Esperanto · estremeñu · euskara · français · Frysk · Gaeilge · Gàidhlig · galego · Hausa · hrvatski · Igbo · interlingua · Interlingue · isiXhosa · isiZulu · íslenska · italiano · Kiswahili · Kreyòl ayisyen · kréyòl gwadloupéyen · Kurdî · latviešu · Lëtzebuergesch · lietuvių · magyar · Malagasy · Malti · Nederlands · Nedersaksies · norsk bokmål · norsk nynorsk · occitan · Oromoo · oʻzbekcha/ўзбекча · Plattdüütsch · polski · português · română · shqip · slovenčina · slovenščina · Soomaaliga · suomi · svenska · Tiếng Việt · Türkçe · Vahcuengh · vèneto · Wolof · Yorùbá · Zazaki · српски / srpski · беларуская · български · қазақша · македонски · монгол · русский · тоҷикӣ · українська · Ελληνικά · Հայերեն · ქართული · नेपाली · मराठी · हिन्दी · भोजपुरी · অসমীয়া · বাংলা · ਪੰਜਾਬੀ · ગુજરાતી · ଓଡ଼ିଆ · தமிழ் · తెలుగు · ಕನ್ನಡ · മലയാളം · සිංහල · བོད་ཡིག · ไทย · မြန်မာဘာသာ · ລາວ · ភាសាខ្មែរ · ⵜⴰⵎⴰⵣⵉⵖⵜ ⵜⴰⵏⴰⵡⴰⵢⵜ‎ · አማርኛ · 한국어 · 日本語 · 中文(简体)‎ · 中文(繁體)‎ · 吴语 · 粵語 · ייִדיש · עברית · اردو · العربية · پښتو · سنڌي · فارسی · ދިވެހިބަސް
その他の言語このウィキの翻訳を支援してください

インポートガイドラインは、自動編集に関する行動規範Automated Edits code of conduct と共に、 OpenStreetMap データベースにデータのインポートをする際に OpenStreetMap の歴史を通して学んできた数多くの教訓として従うべきものです。インポートは他の編集よりも慎重かつ注意深く計画し実行する必要があります。悪いインポートは既存のデータと地域のマッピングコミュニティの両方に重大な影響を与えるからです。 Data Working Group はガイドラインを満たさないインポートを検出し阻止するために OSMF が立ち上げました。そのため、これらのガイドラインに従わない場合は、アカウントがブロックされる可能性があります。

インポートは、マッピングコミュニティを作ったり、マッピングパーティを運営したり、より多くの協力者を得るための広報活動をしたりすることの代わりとして行うべきではありません。もちろん、これに関する議論はすべて、インポートメーリングリスト議論ページのような形でオープンになっています。

プロセス

もし、市/郡/県/国の行政機関、非営利団体、その他の組織、個人などが、 OpenStreetMap の品質を向上させるために使うことができる良いデータを所有していると思ったら、知る必要があることをここに示します。正しい手続きで始めるための手順を簡単な概要で紹介します。これらのエリアの多くは、このページの以下の節や関連ページで記述されています。

ステップ 1 - 前もって必要とされること

  1. 近所のものに詳細情報の追加するなどして OpenStreetMap の基礎に慣れ親しみましょう。
  2. インポートの失敗事例を確認してください。
  3. あなたがインポートしようとしているデータにはどのような種類のものがあるか、確認しましょう。例えば、道路中心線、建物の形状、水路の配置、住所などがあります。

ステップ 2 - コミュニティによる受け入れ

  1. インポートに関する実際の作業を行うより前に、データのインポートに関する関心があるかどうかを把握するためにコミュニティと連絡を取り合うことを推奨します。地理的な場所が異なれば、インポートに対する受容のレベルは異なります。全く同じ種類のデータであっても、ある地域では歓迎されるものが、別の地域では拒絶されることがあります。
  2. あなたの計画について議論してください。ウィキページへのリンクを含んだあなたの計画を、メールで OSM コミュニティに周知してください。これは、(少なくとも) imports@openstreetmap.org や talk-(your country)@openstreetmap.org やインポートにより直接影響を受ける地域に特化した OSM グループなどにメールを送ることで行うことができます(なお、メールを送る前に http://lists.openstreetmap.org/ の一覧にあるメーリングリストに参加しなければなりません)。このことは、投入を考えているインポートデータがすでにレビューされている可能性も含め、過去の経験を生かした助けになります。地域のユーザーグループOSMF 支部対象地域のメーリングリストをチェックしてください。
  3. コミュニティからの質問に回答できるよう準備してください。それぞれのデータがインポートに適しているかどうか、コミュニティと議論しましょう。データ種別によっては、インポートの手間が少ないものもあれば、そうでないもの(例:道路中心線)もあります。同様に、インポートが広く受け入れられているデータもあれば、まだ明確な同意が形成されていないもの(例:郵便配達の境界線など)も存在しています。
  4. 複雑で、大規模なインポートは、より高い技術を持ち、よく経験を積んだ OSM ボランティアの助けのもと、レビューを受けてください。
  5. 地域で受け入れられることなしにデータのインポートを絶対にしてはいけません

ステップ 3 - ライセンスの承認

  1. OSMにおいてデータを利用する際には、データ所有者からの正しい許諾とライセンスを得ることが必要です。もし、データのライセンスが OpenStreetMap の Open Database License と互換性がない場合、そのデータを用いることはできません。多くの地域ではすでに進歩的なオープンデータポリシーがとられています。また、 ほとんど オープンではあるものの、商用利用を禁止していたり、帰属表示の要件に関する問題によって、競合が起こるデータポリシーを採用している場合もあります。また、既存のライセンスが厳しいと考えられる場合であっても、 OpenStreetMap の Open Database License の条項に従うことについて同意する意思を持っているような行政当局に問い合わせることで、データの利用許諾を得ることが、簡単に進む時もあります。 重要な問題に関するメールの事例については Import/GettingPermission を参照してください。インポートするデータのライセンスに互換性があるかないかの早見表は、 ODbL Compatibility を参照してください。

ステップ 4 - ドキュメント作成

  1. Import/Catalogue のページの表に行を加えて、インポートの許諾とプロジェクトに関する登録を行うことが必要です。
  2. インポートの計画を OSM ウィキに記述することが必要です。あなたの計画の詳細について記述したウィキページを作成してください。計画にはデータを OSM XML 形式に変換する方法、作業を分割する方法、データの結合の方法、 GIS の属性を OSM のタグに割り当てる方法、データの単純化を行う方法、データに問題が発生した時の復元の計画、変更セットのデータサイズの制限、品質保証の計画などが含まれなくてはなりません。これらの項目に関する例は、 Import/Plan Outline で確認することができます。
  3. データ所有者からの要求があれば、確認事項を協力者の一覧に追加する必要があります。

ステップ 5 - インポートのレビュー

  1. インポートメーリングリストに参加し、インポートについてレビューの投稿を行う必要があります。これにはメーリングリストへの参加が必要です。プロジェクトがレビューされるまで、決してデータをアップロードしないでください。なお、 imports-us@openstreetmap.org メーリングリスト(またはその他の地域のメーリングリスト)は公式のものと認定されておらず、 imports@openstreetmap.org の代用にはなりません。
  2. 可能であれば、レビューに供することができるデータの準備と作成をしてください。

ステップ 6 - アップロード

  1. 立案した計画に従ってください。
  2. 進捗状況を記録してください。
  3. コミュニティに対して、行った作業に関する最新情報を伝えてください。
  4. インポートの実施時期を告知してください。
  5. インポート専用のアカウントを利用する必要があります。

主な考慮事項

提案したインポートの議論

あなたが提案するインポートについて各ステップでコミュニティと議論することは重要です。とりあえずは Potential Datasources のページに項目を追加してください。そこにはデータのライセンス及び既存データと比べた正確さについて、あなたが気づいたことを記述することができます。もしスペースが足りなければ、そのデータソースに関する新規ページを作ってリンクしてください。

あなたが提案するインポートについて imports@openstreetmap.org メーリングリスト(mailing list)上で議論すると ともに 、適当なローカル・コミュニティとも議論してください。多くのローカル・コミュニティが彼ら自身のウィキページメーリングリストを運営しています。類似の計画を持つ他の人達とも調整を行ってください。

同一のもしくは類似したインポートがすでに議論されている場合にも、ローカルコミュニティとの議論を行う必要があります。これは、ローカルコミュニティのユーザがインポートの計画を認識するとともに、データへのダメージが発生する前に、彼らが問題点やコンフリクトを挙げることができるようにするためです。これは、特にインポート予定のデータがすでに長い時間入手可能な状態になっているのに一度もインポートされていない場合には必ず行うべきことで、そうした状態はローカルコミュニティとの議論を行わずにインポートしていいということにはなりません

常に最初に行うべきは、ライセンスと正確性に関してあなたが行った調査についての議論です。たとえ議論の結果、そのデータが基準を満たしていないという結論に至ったとしてもがっかりしないでください。 Potential Datasources のページに rejected (却下)と書き入れ、その決定の理由を記録しておいてください。このような決定を文書として残すことは、それ自体が有益な貢献です。もしデータが利用可能という結論に達した場合にはインポート用のスクリプトのインポート手段などに関する議論へと移行してください。

人道支援、災害対応、開発に関するインポートに関しては、 HOT (できれば HOT メーリングリスト)にも追加で相談してください。

インポートを文書化する

インポートを行うことになったら、ウィキ上にそれに関するページを作成して全ての詳細を記述してください。次に Import/Catalogue のページにエントリを追加し、あなたが作成したページへリンクしてください。また、地域のマッピングプロジェクト(Mapping Projects)のページからもリンクを貼ってください。作成したページには以下の事項について詳しく記述してください。

  • データソースの正確性及びライセンス(Potential Datasources にも概要を記述)
  • 使用する予定のソフトウェア(JA:Import/Software)。使用しているソースコードも共有してください。
  • 他のデータ形式から OSM 形式に正確に変換する方法
  • 変換後のデータがどう見えるか。使用される正確なタグ。
  • テスト用データベース上にインポートされたサンプルデータへのリンク
  • インポートを行うユーザー名や、変更セットのタグ付け方法の詳細

インポート進行中は次の項目も記述してください。

  • 実際にインポートされた本番環境上のデータ例へのリンク

なお、相談後にインポート範囲を変更した場合は、相談が無効になります。データセット X のインポートの承認後に、 X+Y のインポートの承認を受けることはできません。

データのライセンスに問題がないか確認する

私たちは「自由(free)な」データだけに関心を持っています。 私たちのデータは OpenStreetMap License のもとで公開できなくてはなりません。利用可能なパブリックドメインのデータソースも確かに存在しますが、その量はごく僅かですし、それ以上に複雑な問題があります。

2012年9月に OpenStreetMap はデータのライセンスを Open Database License に移行しました。そのため、インポートするデータはこのライセンスと互換性がなくてはなりません。さらに、インポート用のアカウントは、コミュニティが求めた場合その他のフリー・オープンなライセンスへの再ライセンスへ移行する条項を含む Contributor Terms に同意する必要があります。

あなたはインポートを行う者として追加的な著作権を主張してはなりません。例えば、もしあなたがパブリックドメインのデータをインポートした場合、インポートされたデータの使用を制限する求めを行うことはできません。あなたのインポート用のアカウントは、インポートしようとしているデータの元々の作成者によって付与された許諾事項について、拒絶してはいけません。

また、帰属表示の必要について、その詳細を記述してください。私たちは帰属表示について、複数の方法を提案することができます。私たちのウェブサイト(ホームページではなく、このウィキの協力者のページ)上、また大規模な貢献の場合には www.openstreetmap.org/copyright 上で提供者のクレジットを明示ことができます。また、インポート編集を行うユーザーのアカウントに関連付けて、提供者に関する情報へリンクすることもできます。これはつまり寄付されたデータの供給源を編集履歴によって辿ることができることを意味します。さらに、私たちの基本的なデータとして'source'タグにデータの供給源の名称を付与することもできます。これはより目立つ方法でしょうが、その後のマッピングを行う編集者によって削除される可能性があります。"author" を使えば削除されることはありません。私たちが絶対にしてはならない事は、特定のデータ提供者のクレジット表示を、OSMのデータやレンダリングを利用するエンドユーザに要求することです。これを念頭に置くと、私たちが提案する帰属表示の方法は十分でないかもしれませんし、実際に本来のデータの "作成者" から不十分であるとみなされるかもしれません。

またしばしば、互換ライセンスのもとで利用可能とされていたデータが、元をたどるとフリーではない思われるソース由来のものだったということもあります。例えば OSM では、 Wikipedia 上の幾つかの地理データが Creative Commons ライセンスで利用可能であると広く考えられていますが、そのデータの一部は単純に Google マップに由来するもので、それゆえ実際には上記のライセンスで利用することはできません。これらのケースでは、ライセンスの記述がどうであれ出所の怪しいデータをインポートしないことが、コミュニティにとっての模範的な判断となります。あとになって後悔するより、ここは安全第一でいくべきです。

インポート専用アカウントを使用する

インポート用に新規アカウントを作成してください。自分自身が普段使っているユーザアカウントは使用してはなりません。インポート用のアカウントのユーザページは、データソースとデータを対応させ、インポートの詳細を結びつけるために用いられます。さらに、帰属の表示がアカウントの表示名の中、あるいはユーザー・ページ上に記載されることがありますが、これは帰属をタグとして埋め込むよりも良い方法です。ユーザーの編集履歴はソースの永続的な記録であり、これによってタグが汚されたり、データベースが大きく圧迫されたりすることがないからです。このような理由から、インポート用アカウントの作成は source=* タグを使用するよりも好ましい方法です。分散型/コミュニティでのインポートの場合には、それぞれの人が、例えば "osm ユーザ名"_importのような、インポート専用のアカウントを各々作成してください。それぞれのインポートは、同一のユーザアカウントから行われる必要はありません。

user:Aaron Lidman による素晴らしいコツがあります。もしすでに Gmail のアカウントがある場合、メールのエイリアス機能を使用し、インポート用の新しい OSM アカウントを、「メールアカウント+何か@gmail.com」の名前でサインアップすることです。たとえば、 johnsmith+anytownimport@gmail.com などとします。 Gmail は OSM のメールを通常のメールアカウントに配信します。これによって、1つのメールアドレスで複数の OSM インポートアカウントを作ることができます。

このルールに従わない場合、 DWG によって、アカウントが一時的にブロックされる原因の一つになります。

正しいタグを使用する

インポートには、新たに独自のタグセットを作るのではなく、 OSM コミュニティによく知られているタグを用いる必要があります。

インポートするデータには、独自の ID 番号のようなメタデータが付いているかもしれません。このようなメタデータが OSM にとっても使いやすいものであるのであれば、独自のプレフィックスを定義した上で、それらのメタデータタグを利用してください。たとえば TIGER のインポートでは "tiger:" プレフィックスが使われています。 TIGER オブジェクトの ID のタグは "tiger:tlid" となります。

しかし、何でもかんでもメタデータにするのはやめてください。 OSM は検証可能なものにしか関心がありません。これには(例えば)他のデータベースからの外部キーは、将来のデータの保守に絶対必要でない限り含みません。あなたのデータソースには膨大な種類のフィールドがあるかもしれませんが、 OSM のデータ要素が膨大な数のタグを持つと扱いづらくなります。バランスを取ってください。どのフィールドが OSM コミュニティにとって有益なのかを(議論して!)選別してください。

データの上にデータを重ねない

従来の GIS システムとは異なり、 OpenStreetMap にはレイヤーの概念がありません。データ上に重ねて置かれたデータは混乱の元でしかありません。これは生身のユーザーが通常の OpenStreetMap エディタで作業を行う際に障害となります。 Duplicate nodes map を見ればインポート結果がこのガイドラインに適合したかどうかを知ることができます。(悪名高い TIGER のインポートでも頻繁にこの問題が発生しましたが、悲しいことに、更に多くの問題が最近のインポートによって生じています。)

もしあなたのデータが従来のレイヤー付き GIS 形式なら、別のアプローチをとる必要があります。レイヤーをマージして、適切なタグ集合を導き出しても良いでしょう。あるいは直接インポートすることを諦め、他のユーザーたちに手作業でインポートしてもらうためのソースや、トレースするための WMS (例えば Natural Resources Canada -Toporama のような)を準備するのも良いでしょう。

すでに OSM にある程度のデータがある場所にデータをインポートするならば、このデータに正しい方法で結合するか、既存のデータに重複する地物のインポートを抑止するかする必要があります。明確に良くなる場所に限って、これは滅多にないことですが、現在のデータをインポートするデータに置き換えてください。

簡素化について検討する

しばしば shape ファイルには必要以上の情報が含まれていることがあります。たとえば必要以上に多くのノードが含まれるカーブや、3個以上のノードが含まれている直線などです。特に、数メートルごとにノードがあったり、解像度が不十分か逆に高すぎるせいでギザギザに見えるような、巨大な landuse エリアなどで見られます。 Map Shaper のようなツールを使うと、メタボ気味のファイルをシェイプアップさせることができます。データが Potlatch 上でどのように見え、どのように扱われるのかを常に考えるように心掛けてください。

サーバー資源に配慮する

大量のデータをインポートする際には、サーバーに過負荷をかけないように注意してください。 TIGER のインポート作業は、中央サーバーをダウンさせないように数ヶ月の期間にわたって分散させる必要がありました。データを分割してインポートするか、インポート・スクリプトの実行速度を遅くしてください。もしも不明な点があるなら、 System Administrators に連絡してください。

データベースにダメージを与えないよう細心の注意を払う

データベースにダメージを与えないように細心の注意を払ってください。乱雑なインポートを残さないようにしてください。 iDPotlatch で作業している名もない OpenStreetMap の協力者たちがその作業をコツコツと修正するであろう姿を想像してください。 JOSM ならば乱雑なデータのもつれをほどくのに少しは便利ですが、なお大変な作業ですので、必要ならば自分自身でやってください。

インポートが'上手くいかない'、または途中でアップロードを中断する必要に迫られた場合は、すぐにそれをリバート(復元)してください。支援が必要なら Imports または Talk、もしくはその両方に連絡してください。もし元に戻す方法を知らないのであれば、そもそもインポートを行うべきではありません。

関連情報