JA:Any tags you like

多くの一般的な興味深い地物が既にMap Features にあり、そのタグ付けを利用することが推奨されています。そうしないと、他のユーザがいずれはあなたの貢献をそのスキームに合うように変換することになります。

Contents 1 マップフィーチャに無いタグのドキュメント化 2 提案(proposal)の作成時期 3 マップすべきでないもの 4 新しいタグ用の構文規則 5 使用する文字 6 スタイルガイド?

マップフィーチャに無いタグのドキュメント化

good practiceをフォローし、Map Features、Proposed features、Rejected features、Proposed Relations それにmailing lists' archives を検索してもまだマップしたいもののタグが見つかりませんか？ タグの付け方を提案してくれるリポジトリとしては、おそらくTagwatch がいちばん役に立つでしょう。データベースで実際に使われているタグ、及びその使用頻度がリスト化されています。またひとつのオブジェクトに関する特定のタグとの組み合わせで使われている他のタグもリスト化されています。

注意していただきたいのですがOpenStreetMap はノード、ウェイ及びエリアに割り当て可能なタグに関していかなる内容制限もありません。何であれ好きなタグを使えますが、たとえ自明であってもここOpenStreetMap のwiki にドキュメント化してください(New Features参照。)

ドキュメント化することにより、他の人があなたのフィーチャを見つけたり、あなたの近くで見つけたマッピング誤りを訂正してくれることだってできます。

ドキュメント化しておくと、後から誰かがあなたの追加したフィーチャの上位セットのタグ付けを提案する際に、特に役に立ちます。そうすれば、あなたの経験とフィーチャは提案プロセスに組み込まれ、ひょっとすると承認されれば新しいスキームに変換されることだってあり得ます。

使用するタグの選択 例えば、Siberian_Flying_Squirrelの危険にさらされている全ての巣をマップしたいと思ったら、endangered_nest=Siberian_flying_squirrelというページを作って、そのページについて、それが何のためのものなのかをドキュメント化してください。誰が別の人が後から、絶滅危惧種の他の側面についてドキュメント化するための、異なる、より構造化されたスキームや、発見された糞をドキュメント化できるようなタグ付け - あらゆる建設からの保護に使われるケース - も提案できるように準備しておいてください。そして最後にはあなたの古いエントリーを変換することになるでしょう。

例えば、マップのオリエンテーリングで使われている分類基準を IOF Standardsに相談して、それらが何らかの役に立つのか、そしてあなたの新しいタグがそれらのユーザのニーズと互換性がとれるのか、確認することができます。他の類似ドキュメントも同様に存在します。

提案(proposal)の作成時期

下記いずれかの条件に当てはまるなら、あなたの地物用にproposalを作成すべきです:

1. あなたの地物が一般的に興味深いものである
2. それをどうモデル化すれば良いか分からない
3. 最新のタグ付けに提案されたフォームが拒絶された
4. 既に使用中のタグに意味づけを変えたい

(提案の作成は、あなたの地物がメインマップに現れるための要件でも無く、あなたの地物をメインマップに載せるための成功しやすい提案プロセス、保証されたやり方でも無い、ということに注意してください。しかしながら、もしあなたの地物が提案プロセスを経て、多数に承認された場合には、もちろんあなたは多くの人からその地物を表示させるように頼まれるでしょう。そしてその地物がメインマップにレンダリングされるチャンスを広げるのです。)

マップすべきでないもの

OpenStreetMapデータベースのエンティティは、いくつかの地理的なプロパティや、地理的な性質を持つオブジェクトと関連しているべきです。そのため、電波基地局の形式を利用して無線LANのホットスポットを記載することは許容されますが、そのスポットからの電波強度をその周辺のあらゆる地点でタグ付けして記録することは好ましくない記載として見られることがあります。そのような情報は、OSM以外の自身のサービスで保存したほうがよいでしょう。しかし、もしその情報をあえてOSMに記載しようとする場合は、誰もその行為を止めることはできません。

新しいタグ用の構文規則

これは、現在のMap featuresタグおよび最近の提案に基づいて、新しいタグを発明している人々が使っている既存の慣習をドキュメント化する試みです。修正や広く使われている追加フォームなどは喜んで受け入れます！

• タグ とはソフトウェアに縛られたユニコード文字列からなる(key, 値) ペアであり、しばしば議論の中ではkey=値 として書かれます。
• The value part may be separated into multiple values for some but not all keys by separating the string with semicolons. Keys which permit this sort of interpretation are individually documented on the Wiki, but in general those keys whose potential values are mostly drawn from a documented set of underscore_separated_lowercase_strings are more likely to permit this kind of interpretation.
• key部分用に選ばれた文字列は何らかの慣習的なフォームも持っています:
  • Ideally, a key is one word, in lowercase. It can be either a category (like highway) or a property (like width). Properties take value keys (e.g. width=2), categories often take keys which further refine the categorisation (e.g. highway=motorway).
  • When that can't be the case, a key should be one concept, whose words are underscore_separated. This avoids some whitespace issues, and has generally come about because OSM guys also tend to be programmers and like the syntax.
  • もっと複雑ないくつかのキーは'コロンで区切られた'複数のワードやコンセプトから成ります。これらは左から右へ自然に読めるようにすべきです; 既に一握りのパターンは広く使われています:
    1. いくつかのプログラミング言語に似たスタイルで、シンプルなネームスペースのプレフィックス。Bundles loosely-related information together in a way that doesn't clash with other OSM tags. Ideal for data imports from other sources!
       • tiger:county=*, tiger:upload_uuid=* - all to do with US TIGER data uploads
       • KSJ2:lat=*, KSJ2:curve_id=* - tags from the Japan KSJ2 import
    2. Bundles of tightly-related information, which together express a single fact consisting of several fields. Almost property-like. Great for addresses and unusual naming patterns.
       • name:left=*, name:right=* - 片側ずつ名前が異なる通り(w.r.t. way direction arrow?)
       • addr:housenumber=*, addr:street=* - 場所の名前に全て関連
    3. 言語コードによる修飾。
       • name:en=*, name:cy - the English and Welsh names for a feature
       • note:ja=* - 日本語による備考
    4. 割と一般的ではない。Pattern 2, but done in a generative manner where sub-parts refer to other defined keys. This is almost meta-tagging. Almost.
       • source:name=* - the source for the the name tag is ...
       • source:ref=* - the source for the the ref tag is ...
• 多くのタグ付けスキームで使われている繰り返しによる詳細化という一般的なパターンがあります。これには、そのスキームは時が経つにつれてより詳細に補足することができ、一方で後方互換が取れる、という利点があります:

highway=crossing

crossing=uncontrolled

使用する文字

ユニコード(utf-8)の値はどれでも使用できます。実際、ほとんどのキー（highwayなど）および区分される値(trunk_linkなど)は小文字、アンダースコアおよびコロンを使用しています。これらの文字列に対して、以下のように様々なソフトウェアでトラブルと引き起こしそうな文字の利用を避けるのは良いアイディアです:

• 半角スペース(Whitespace) 半角スペースの代わりにアンダースコア '_' を使うべきです、キー値の最初や最後に半角スペースを使うのは避けてください
• <>&/+?#%'"\ XML、HTMLおよびURLsに含まれる特殊文字や引用に使われるものなどは避けるべきです
• = タグとキーを分ける文字として多くの箇所で使われているので等号の使用は避けてください。
•  ; セミコロンの使用については議論中です

フリーフォームの値(例. nameキーで使われているようなもの) は考えられるあらゆる値を使用しています。

スタイルガイド?

あなたが望むなら、これはスタイルガイドとして扱うこともできますが、実際はそうではありません。結局のところ解釈はユーザ次第ですし、本当に適用される唯一の原則はKISS ("Keep It Simple, Silly（馬鹿のように単純にしろ）")、あるいは"たぶんうまく行くいちばん簡単なことをやれ"ということです。あなたのタグ/提案をより多くの人々に採用してもらいたければ明確で単純であればあるほど良いです。