JA:Relation:site

サイトリレーションは、全体として単一の属性を持つが、他のデータタイプでは正確に表現できない複数のオブジェクトをグループ化するために使用されます。サイトリレーションは、マルチポリゴンリレーションと同様に、単一の不連続なジオメトリを表現することができ、単なる偶然の一致である組織的なリレーションや空間的なリレーションとは対照的です。

サイトリレーションはデータ利用者間のサポートが不十分であるため、マッピングしようとしているものがより適切にサポートされている他の手段を検討してください。

理論的根拠

サイトリレーションは、共通の名前やその他の共通の特性を持つ現実世界の地物を、単一の図形やマルチポリゴンリレーションを構成する複数のエリアで正確に表現できない場合に適しています。つまり、サイトリレーションは地物に1つまたはそれ以上のノードや、エリアで正確に置き換えることができない線状の地物を組み込む必要がある場合に適しています。

詳細なコンテキストと例は、 proposal page を参照してください。

マッピング方法

リレーションを作成し、type=site を追加します。 さらに、 amenity=university、 site=parking、 site=piste、 power=plant などの、サイトリレーションが表す機能を定義する主要タグが必要です。

name=* など、特性を表すために必要な他のタグをすべて追加します。

タグ site=* は、geodesic、stop_area、parking、wind_farm、mall、pisteなどの値と共に、サイトの種類をさらに特定するために使われることがあります。ただし、これらの値のほとんどは文書化されていません。

次に、ロールの指定なしでメンバーを追加します。

メンバーには、ノードまたはウェイを含めることができます。

ソフトウェアサポート

原則として、サイトリレーションはマップレンダラーと検索エンジンによってサポートされます。サイトリレーションはメンバーによってはGeoJSON及び、FeatureCollectionまたはMultiPointといった類似のフォーマットに変換できます。サイトリレーションが適切に使用されたとき、ユーザーが地図上でラベル付けされたり検索結果にリストされた属性を持つ実在の地物に対応します。そのようなサポートを提供するデータ利用者はごく少数ですが、例外としてOpenSnowMap[1] があります。対照的に、マルチポリゴンはより直感的で多くのソフトウェアにサポートされています。

代替案

英語でサイトと呼ばれる可能性があるものすべてのためにサイトリレーションを作成する必要はありません。

例えば、

• 建設現場には多数の建設中の道路や建物があるかもしれませんが、これらを逐一サイトリレーションに追加することはエラーが発生しやすく、壊れやすく、データ利用者が理解しにくくなります。その代わりに、建築中のすべてを含む単純な landuse=construction エリアを描いて、建築中のオブジェクト自体に highway=construction、 building=construction、またはライフサイクルの接頭辞 construction:*=* を使用します。リレーション化されていないOpenStreetMapのすべてのオブジェクトは本質的にその周囲と比較できる位置を持つため、データ利用者は空間クエリによって、建設現場に何があるかを自動的に推測することができます。
• 航空博物館の敷地内には多くの航空機、ベンチ、旗竿や建物がありますが、それらは時間と共に変わる可能性があります。手の混んだサイトリレーションの代わりに、プロパティ全体を一つの tourism=museum エリアで囲みます。例えば、このエリアのメンテナンスは以前のサイトリレーションと比べてずっと簡単になりました。

リレーションの各メンバーをエリアで正確に表現できる場合は、各メンバーをエリアに置き換えて outer ロールを付し、リレーションのタグを type=multipolygon に付け替えて、マルチポリゴンに変換します。例えば、単一の学校のキャンパスと考えられるものが実際には同じIDを共有する連続していない部分で構成されている場合、 amenity=school タグが付けられたマルチポリゴンリレーション内のouter outerロールを持つ閉じたウェイとしてマッピングします。

リレーションはカテゴリではないため、サイトリレーションはそのメンバーがたまたまいくつかの特徴を共有しているが共通のアイデンティティを持っていない場合にも不適切です。

例えば、

• 例えばある市内の各学校のキャンパスが明確なアイデンティティを持っていて、それらが単一のものとして考えられていない場合は、それらを各種のリレーションに追加することは避けてください。代わりに、各キャンパスに同一の operator=* または brand=* タグを適切に付けてください。
• ファーストフードチェーンのそれぞれの場所はそれ自体がファーストフードレストランであるため、関係のない amenity=fast_food 地物として独立している必要があります。 name=*、 operator=*、 owner=*、または brand=* の一致する値を使用して、チェーン内のレストランが何らかの関連があることを確定します。（他の種類の地物の場合、 network=* の値を一致させることもこの目的に役立ちます。）
• 集合住宅は、 landuse=residential と residential=apartments のタグが付けられたエリアに含まれる、 building=apartments エリア及びその他の地物で構成されている必要があります。各建物がたまたま building=* の同じ値を共有していても、全体で一つの建物とはみなしません。

別の町にあるなど、2つの地物が離れている場合、それらが共通のIDを共有していたり同じサイトに所属している可能性はほとんどありません。

歴史

2010年2月、 ドイツの公共交通機関の地物を表すために、 site=stop_area というタグが付けられた41,000以上のサイトリレーションがソースタグ「naptan_import」を付けてインポートされました。このような公共交通機関の停車場所の地物は一般に、 type=public_transport リレーションに public_transport=stop_area を追加して表されます。2021年の時点で、これらのリレーションは全世界のサイトリレーションの26%を占めています。

2010年3月、 man_made=survey_point 地物のグループを関連付けるために、 site=geodesic のタグが付けられた72,000以上のサイトリレーションが、フランスのソース "©IGN 2010 dans le cadre de la cartographie réglementaire" からインポートされました。2021年の時点で、これらのリレーションは全世界のサイトリレーションの46%を占めています。

関連情報

• type=multipolygon - マルチポリゴンリレーション
• Relations/Proposed/Site - この地物に関する主要な提案
• Proposed features/Site Perimeter - 'perimeter' ロールについての補助的な提案
• Proposed_features/Group_Relation