JA:何でも好きなタグを
注: 一般的な関心事となる地物や特徴の多くは、すでに地物や特徴の一覧にあり、そちらで提供されているタグ付けを使用することが推奨されています。そうしなければ、他のユーザーがあなたの編集をその方式に合うように変換するかもしれません。
地物や特徴の一覧にないタグの文書化
グッドプラクティスをフォローし、地物や特徴の一覧、提案中のもの、却下されたもの、提案中のリレーション、メーリングリストのアーカイブを検索しても、地図に描こうとしているタグが見つからないかもしれません。タグ付け方法を提案してくれるリポジトリとしては、おそらく Taginfo が最も役に立つでしょう。データベースで実際に使われているタグ、及びその使用頻度がリスト化されています。またひとつのオブジェクトに関する特定のタグとの組み合わせで使われている他のタグもリスト化されています。
注意していただきたいのですが OpenStreetMap ではノード、ウェイ及びエリアに割り当て可能なタグに関していかなる内容制限もありません。好きなタグを何でも使えますが、たとえ自明のものであっても、この OpenStreetMap ウィキに文書化してください(新しい地物を参照)。
文書化すると、他の人があなたのの地物を見つけたり、近くに来た人がマッピングの誤りを修正したりできるようになります。
文書化しておくと、後から誰かがあなたの追加した地物の上位セットのタグ付けを提案する際に、特に役に立ちます。そうすれば、あなたの経験と地物は提案プロセスに組み込まれ、ひょっとすると承認されれば新しいスキームに変換されることだってあり得ます。
使用するタグの選択
例えば、絶滅危惧種であるタイリクモモンガのすべての巣をマッピングしたいのであれば、 endangered_nest=Siberian_flying_squirrel というページを作って、そのページについて、それが何のためのものなのかを文書化してください。誰が別の人が後から、絶滅危惧種の他の側面について文書化するための、異なる、より構造化されたスキームや、発見された糞を文書化できるようなタグ付け - あらゆる建設からの保護に使われるケース - も提案できるように準備しておいてください。そして最後にはあなたの古いエントリーを変換することになるでしょう。
例えば、マップのオリエンテーリングで使われている分類基準を IOF 標準に照らし合わせて、それらが何らかの役に立つのか、そしてあなたの新しいタグがそれらのユーザのニーズと互換性がとれるのか、確認することができます。他の類似ドキュメントも同様に存在します。
提案(proposal)の作成時期
下記いずれかの条件に当てはまるなら、地物や特徴のために proposal を作成すべきです。
- その地物や特徴が一般的な関心事である
- それをどうモデル化すれば良いか分からない
- 最新のタグ付けに提案された形式が拒絶された
- 既に使用中のタグの意味づけを変えたい
(提案の作成は、あなたの地物がメインマップに現れるための要件でも無く、あなたの地物をメインマップに載せるための成功しやすい提案プロセス、保証されたやり方でも無い、ということに注意してください。しかしながら、もしあなたの地物が提案プロセスを経て、多数に承認された場合には、もちろんあなたは多くの人からその地物を表示させるように頼まれるでしょう。そしてその地物がメインマップにレンダリングされるチャンスを広げるのです。)
マッピングすべきでないもの
OpenStreetMap データベースのエンティティは、いくつかの地理的なプロパティや、地理的な性質を持つオブジェクトと関連しているべきです。 例えば、無線LANのホットスポットの基地局の位置を記載することは許容されますが、電波強度をもとにその周辺の多数の地点でタグ付けすることは好ましくありません。そのような情報は、別のサービスで保存したほうがよいでしょう。
新しいタグ用の構文規則
検証可能性に関してGood_practiceのページに文書化されたコミュニティの合意を考慮してください。過去のものや一時的なものや仮説による地物、評価のような恣意的なもの、法令などはマッピングしないでください。
これは、現在の地物や特徴の一覧タグおよび最近の提案に基づいて、新しいタグを発明している人々が使っている既存の慣習を文書化する試みです。修正や広く使われている追加フォームなどは喜んで受け入れます!
- タグとはソフトウェアで管理された Unicode 文字列の組み合わせ(キーと値)であり、議論の中ではよくキー=値と記述されます。
- 値の部分は、全てではありませんが、一部のキーにおいて、セミコロンで区切った文字列で複数の値に分かれていることがあります。この解釈方法を許すキーは、ウィキに個別に記述されています。セミコロンによる値区切りを参照してください。
- キーの部分に選択された文字列にも、慣習的な形式がいくらかあります。
- キーは小文字の一語であるのが理想的です。カテゴリ(highwayなど)や属性(widthなど)のどちらでも構いません。属性はいくつでも(おそらく無限に)持つことができ、値や数値を取ることができ(例えばwidth=2)、カテゴリはもっと洗練された分類の値を採ります(例えばhighway=motorway)。
- そのようにすることができない場合、キーは語をunderscore_separatedのようにアンダースコアで区切るという単一の考えに従うべきです。 OSM の人々はプログラマーである傾向があり、このような文法を好むので、一部の空白の問題を防ぐためによく利用します。
- 一部のキーはより複雑で、複数の語から成り、コロンで区切るという考え方をします。これは左から右に自然に読めるようにするべきです。パターンのいくつかはすでに広く使われています。
- 単純な名前空間として接頭辞を付ける方法で、一部のプログラミング言語に似た形です。緩く関連を持つ一緒に情報をまとめ、他の OSM のタグと衝突しないようにする方法の一つです。他の情報源からのデータインポートに便利です。
- tiger:county=*, tiger:upload_uuid=* - アメリカの TIGER データアップロードで行われたもの全てです
- KSJ2:lat=*, KSJ2:curve_id=* - 日本の KSJ2 インポートによるタグです
- 複数の欄を構成する一つの事実を合わせて説明する、緊密に関連した情報をまとめます。多くは属性のようなものです。住所や普通ではない名称のパターンでよく使われます。
- name:left=*, name:right=* - 方向によって名称が異なる通り(w.r.t. way direction arrow?)
- addr:housenumber=*, addr:street=* - 場所の名前に全て関連
- 言語コードによる修飾。 JA:名称#地域化・多言語化 (Localization) を参照。
- 比較的一般的ではありません。パターン2と同様ですが、他に定義されるキーを参照する部品としての生成規則として行われます。これは大体がメタタグです。
- source:name=* - name タグ用のsource...
- source:ref=* - ref タグ用のsource...
- 単純な名前空間として接頭辞を付ける方法で、一部のプログラミング言語に似た形です。緩く関連を持つ一緒に情報をまとめ、他の OSM のタグと衝突しないようにする方法の一つです。他の情報源からのデータインポートに便利です。
- 繰り返しによる詳細化という一般的なパターンがあり、多くのタグ付け方式で使われています。時が経つにつれて、後方互換性を確保しつつ、だんだん詳細化することができるという利点があります。
使用する文字
Unicode 文字(utf-8)の値はどれでも使用できます。実際、ほとんどのキー(highwayなど)および区分される値(trunk_linkなど)は小文字、アンダースコアおよびコロンを使用しています。これらの文字列に対して、以下のように様々なソフトウェアでトラブルと引き起こしそうな文字の利用を避けるのは良いアイディアです:
- 半角スペース 半角スペースの代わりにアンダースコア '_' を使ってください。キー値の最初や最後に半角スペースを使わないでください。
- <>&/+?#%'"\ XML、HTML、URLに含まれる特殊文字や引用に使われるものなどは避けてください
- = タグとキーを分ける文字として多くの箇所で使われているので等号の使用は避けてください。
- ; セミコロンの使用については議論中です
フリーフォームの値(例. nameキーで使われているようなもの) は考えられるあらゆる値を使用しています。
スタイルガイド?
あなたが望むなら、これはスタイルガイドとして扱うこともできますが、実際はそうではありません。結局のところ解釈はユーザ次第ですし、本当に適用される唯一の原則はKISS ("Keep It Simple, Silly"(馬鹿のように単純にしろ))、あるいは"たぶんうまく行くいちばん簡単なことをやれ"ということです。あなたのタグ/提案をより多くの人々に採用してもらいたければ明確で単純であればあるほど良いです。
関連項目
- Just Map
- Good Practice
- Jochen Topf による How to invent tags