JA:Import/Guidelines
例によって、このプロジェクトには厳格な規則が僅かしかありません。ただしガイドラインが幾つかあります。もちろん、それらのガイドラインに関する議論は大いに結構ですので、メーリングリスト（Mailing lists）及びディスカッションのページ（discussion page）を活用してください。
インポート一覧（catalogue of imports）を見て、他の人がどのようにインポートを行ったかを知ることもできます。
Contents |
コミュニティを作る
OpenStreetMap は、巨大なマッパー・コミュニティの関心を得ることによって、大規模な地図を造り上げようとしています。データのインポートを行えばカバー率は急速に向上するかもしれませんが、最近のシミュレーション（recent simulations）では、インポートされたデータがコミュニティの成長に問題をもたらす恐れがあることが示されています。本当は、外に出て多くのマッピングパーティー（mapping parties）を開いたり、宣伝のチャンスや地元マッパーをゲットすることの方がはるかに重要なことなのです。
データのライセンスに問題がないか確認する
私たちの関心の対象は「自由（free）な」 データだけです。私たちのデータは OpenStreetMap License のもとで公開されなくてはなりません。利用可能なパブリックドメインのデータソースも確かに存在しますが、その量はごく僅かですし、それ以上に複雑な問題があります。
私たちが（現時点で）採用しているライセンス 'Creative Commons Attribution-ShakeAlike 2.0' のもとでさえ、必ずしも他の CC-BY-SA-2 データのインポートが許される訳ではありません。帰属表示の要求に絡む潜在的な問題があるのです。私たちは帰属表示について、複数の方法を提案することができます。私たちのウェブサイト（ホームページではなく、このウィキの Contributors のページ）上で提供者のクレジットを明示ことができます。また、インポート編集を行うユーザーのアカウントに関連付けて、提供者に関する情報へリンクすることもできます。これはつまり寄付されたデータの供給源を編集履歴によって辿ることができることを意味します。さらに、私たちの基本（underlying）データの'source'タグに彼らの名前をセットすることもできます。これはより目立つ方法でしょうが、その後のマッピングを行う編集者によって削除される可能性があります。"author" を使えば削除されることはありません。私たちが絶対にしてはならない事は、特定のデータ提供者のクレジット表示を、エンドユーザーに要求することです。これを念頭に置くと、私たちが提案する方法は十分でないかもしれませんし、実際にオリジナルの "authors" にとって不十分だとみなされるかもしれません。
同じ問題は "クレジットを要求しないパブリックドメイン（public domain apart from we require credit）" と謳われているいかなるデータにも当てはまります。（私たちは、例えば LINZ のデータやカナダ政府のデータに関してこのような疑念を持ちました。）
ライセンスの問題は恐ろしいほど複雑になることがあります。私たちのライセンスが多くの面で様々に解釈され得るということを認識することは重要です。現行のライセンスは、地理データやウィキスタイルの共同作業にそれほどはっきりと適合しているわけではありません。
もしあなたがOSMへのインポートのためにデータの制作者から完全な承諾を得ようとするなら、改変、再頒布、クレジットの有無といった事項に関して、それが何を意味しているのかを確実に説明してください。...そうすれば、多くの人は十分だと認めてくれるでしょう。（例えば私たちは、AND Data を得るために同じ事をしました。）
またしばしば、互換ライセンスのもとで利用可能とされていたデータが、元をたどると非フリーと思われるソース由来のものだったということもあります。例えばOSMでは、Wikipedia 上の幾つかの地理データが Creative Commons license で利用可能であると広く考えられていますが、そのデータの一部は単純に Google マップからコピーされたもので、それゆえ実際には上記のライセンスで利用することはできません。これらのケースでは、ライセンスの記述がどうであれ出所の怪しいデータをインポートしないことが、コミュニティにとっての模範的な判断となります。あとになって後悔するより、ここは安全第一でいくべきです。
その他の考慮すべき重要事項が、現在真剣に議論されている Open Database License への再ライセンスの計画です。あなたのインポートがどのような影響を受けるかを考え、そしてもしあなたが誰かからデータの利用許可を得ようとしているのなら、相手に現状をきちんと理解してもらってください。説明は難しいかもしれませんが、どのみち説明する必要があるのなら早い方が少しはマシです。
インポートについてコミュニティと議論する
あなたが提案するインポートについて各ステップでコミュニティと議論することは重要です。とりあえずは Potential Datasources のページにエントリを追加してください。そこにはデータのライセンス及び既存データと比べた正確さについて、あなたが気づいたことを記述することができます。もしスペースが足りなければ、そのデータソースに関する新規ページを作ってリンクしてください。
あなたが提案するインポートについて imports@openstreetmap.org メーリングリスト（mailing list）上で議論するとともに、適当なローカル・コミュニティとも議論してください。多くのローカル・コミュニティが彼ら自身のウィキページやメーリングリストを運営しています。類似のプランを持つ他の人達とも調整を行ってください。
常に最初に行うべきは、ライセンスと正確性に関してあなたが行った調査についての議論です。たとえ議論の結果、そのデータが基準を満たしていないという結論に至ったとしてもがっかりしないでください。Potential Datasources のページに rejected（却下）と書き入れ、その決定の理由を記録しておいてください。このような決定を文書として残すことは、それ自体が有益な貢献です。もしデータが利用可能ならインポート・スクリプトの実装に関する議論へと移行してください。
インポートをウィキで文書化する
インポートを行うことになったら、それに関するページをウィキ上に作成して全ての詳細を記述してください。次に Import/Catalogue のページにエントリを追加し、あなたが作成したページへリンクしてください。また、ローカルのマッピング・プロジェクト（Mapping Projects）のページからもリンクを貼ってください。作成したページには以下の事項について詳しく記述してください。
- データソースの正確性及びライセンス（Potential Datasources にも概要を記述）
- 利用を予定しているソフトウェア（Import/Software）。使用しているソースコードも共有してください。
- データ形式の変換方法の詳細
- 変換後のデータがどう見えるか。使用されるタグは？
- テスト用データベース上にインポートされたサンプル・データへのリンク
- インポートを行うユーザー名、及び差分がどのようにタグ付けされるかの詳細
インポート進行中は次の項目も記述してください。
- 実際にインポートされた本番環境上のデータ例へのリンク
インポート用アカウントを使用する
インポート用に新規アカウントを作成することを検討してください。この方法は、データソースと関連データを比較したり、インポートの詳細を調べたりする際に非常に役に立ちます。さらに、帰属の表示がアカウントの表示名の中、あるいはユーザー・ページ上に記載されることがありますが、これは帰属をタグとして埋め込むよりも良い方法です。ユーザーの編集履歴はソースの永続的な記録であり、これによってタグが汚されたり、データベースが大きく圧迫されたりすることがないからです。このような理由から、インポート用アカウントの作成は source=* タグを使用するよりも好ましい方法です。
独自のタグ・プレフィックスを定義する
あなたは自身のオリジナル・データに独自のIDのようなメタデータを付けているかもしれません。このようなデータのタグには独自のプレフィックスを定義してください。たとえば TIGER のインポートでは "tiger:" プレフィックスが使われています。TIGER オブジェクトのIDのタグは "tiger:tlid" となります。
何でもかんでもメタデータにするのはやめてください。あなたのデータソースには膨大な種類のフィールドがあるかもしれませんが、多くのタグを持つOSMのデータ要素がそれらと共存するのは難しいかもしれません。大切なのはバランスです。どのフィールドがOSMコミュニティにとって有益なのかを（議論して！）選別してください。
サーバーのリソースに配慮する
大量のデータをインポートする際には、サーバーに過負荷をかけないように注意してください。TIGER のインポート作業は、中央サーバーをダウンさせないように数ヶ月の期間にわたって分散させる必要がありました。データを分割してインポートするか、インポート・スクリプトの実行速度を遅くしてください。もしも不明な点があるなら、 System Administrators に連絡してください。
データを壊さないで！
本当は言うべきではありませんが、あえて言います。OpenStreetMap のデータを壊さないで！ Potlatch で作業している一般的な協力者の視点で常に考え、彼らがあなたの尻拭いを喜んでやるだろうなどと、決して思わないでください。もしあなた自身が Potlatch で作業したことがないのなら、インポートをするべきではありません。JOSM を使えばデータの復旧も少しは楽になりますが、それでもなお面倒な作業なのです。ほとんどのユーザー（とりわけ新規ユーザー）は Potlatch を利用しています。インポートしようとしているデータが彼らの編集成果をスポイルしてしまうのなら、そのデータはいりません。
既存のデータをないがしろにしたり、新規データを既存データの上に重ねてインポートしないでください。一般的に、データ上（後述のデータ・ノートを参照）に別のデータを重ねるのは良くないことですが、加えて、その既存データが生身のユーザーが育てているデータかもしれないということも考慮するべきです。自動的/半自動的な方法でこれを判断して既存データの取り扱いを決めることもできます。たとえば生身のユーザーが活動中の地域においては、既存データをそのままにすると決めても良いでしょう。
インポートの結果が好ましくない、あるいはアップロードを中断した場合は、すぐにそれを元に戻す（revert）ことが必要です。支援が必要なら Imports または Talk、もしくはその両方にコンタクトしてください。もっとも、あなたは事前にテスト用データベースで入念なテストを行っているでしょうから、インポートが悪い結果を招くことはありません。（でしょ？）
もし元に戻す方法を知らないのであれば、そもそもインポートを行うべきではありません。
具体的なデータ・ガイドライン
データの上にデータを重ねない
従来のGISシステムとは異なり、OpenStreetMap にはレイヤーの概念がありません。データ上に重ねて置かれたデータは混乱の元でしかありません。これは生身のユーザーが通常の OpenStreetMap エディタで作業を行う際に障害となります。Duplicate nodes map を見ればインポート結果がこのガイドラインに適合したかどうかを知ることができます。（悪名高い TIGER のインポートでも頻繁にこの問題が発生しましたが、悲しいことに、更に多くの問題が最近のインポートによって生じています。）
もしあなたのデータが従来のレイヤー付きGIS形式なら、別のアプローチをとる必要があります。レイヤーをマージして、適切なタグ集合を導き出しても良いでしょう。あるいは直接インポートすることを諦め、他のユーザーたちに手作業でインポートしてもらうためのソースや、トーレスするための WMS（Natural Resources Canada -Toporama のような）を準備するのも良いでしょう。
簡素化について検討する
しばしばシェイプファイルには必要以上の情報が含まれていることがあります。たとえば必要以上に多くのノードが含まれるカーブや、3個以上のノードが含まれている直線などです。特に、数メートルごとにノードがあったり、解像度が不十分か逆に高すぎるせいでギザギザに見えるような、巨大な landuse エリアでこれを見ることができます。Map Shaper のようなツールを使うと、メタボ気味のファイルをシェイプアップさせることができます。データが Potlatch 上でどのように見え、どのように扱われるのかを常に考えるように心掛けてください。
