|A site relation is used to group several objects together.|
|Status: in use|
|Tools for this tag|
A site relation is used to group several objects which together have a single identity as a whole but cannot be accurately described by other data types. Like a multipolygon relation, a site relation allows you to represent a single discontiguous geometry, as opposed to an organizational relationship or a spatial relationship that is merely a coincidence. Site relations have poor support among data consumers, so consider better supported alternatives for what you are trying to map.
A site relation is appropriate when a single real-world feature, with a common name and other common characteristics, cannot be accurately represented by a single geometry or by multiple areas forming a multipolygon. In other words, a site relation is appropriate when the feature must incorporate one or more point features or linear features that cannot be accurately replaced by areas.
How to map
Create a relation and add type=site. In addition, the relation must have a main tag defining whatever feature the site relation describes. E.g. amenity=university, site=parking, site=piste, power=plant, etc.
Add all other necessary tags to map the characteristics:
Sometimes the tag site=* is used to further specify the kind of site, with values such as geodesic, stop_area, parking, wind_farm, mall, piste, etc. However, most of these values have not been documented.
Then the members are added without having to specify a role.
Members may include nodes or ways.
In principle, site relations could be supported by map renderers and search engines. Depending on its members, a site relation could be translated into GeoJSON and similar formats as a FeatureCollection or MultiPoint. When used properly, a site relation corresponds to an actual feature on the ground with an identity that a user may want to see labeled on a map or listed in search results. However, very few data consumers offer such support; one exception is OpenSnowMap.  By contrast, multipolygons are more intuitive and enjoy widespread software support.
There is no need to create a site relation for everything that may be called a "site" in English. For example:
- A construction site may have any number of roads and buildings under construction, but meticulously adding each of these things to a site relation would be error-prone, fragile, and unlikely to be understood by data consumers. Instead, simply draw a landuse=construction area encompassing everything that is under construction and use highway=construction, building=construction, or the construction:*=* lifecycle prefix on the under-construction objects themselves. Data consumers can rely on spatial queries to automatically infer that something lies within the construction site, because every non-relation object in OpenStreetMap inherently has a location that can be compared to its surroundings.
- An aviation museum features many aircraft, benches, flagpoles, and buildings on site, but each of these things may change over time. Instead of an intricate site relation, surround the entire property with a single tourism=museum area. For example, this area ends up being much easier to maintain than this former site relation.
If each member of the relation can be accurately represented by an area, replace each member with an area, then convert the relation into a multipolygon by retagging it as type=multipolygon and giving each member a outer. For example, if what is considered a single school campus actually consists of multiple discontiguous sections that share the same identity, map each campus as a closed way with outer together in a multipolygon relation tagged amenity=school.
Since relations are not categories, a site relation is also inappropriate if its members coincidentally share some characteristics but do not share a common identity. For example:
- If each school campus in a city has a distinct identity and together they are not thought of as a single unit, avoid adding them to a relation of any type; instead, tag each campus with identical operator=* or brand=* tags as appropriate.
- Each location of a fast food chain is a fast food restaurant in its own right, so it should stand alone as an amenity=fast_food feature without a relation. Use matching values of name=*, operator=*, owner=*, or brand=* to establish that the restaurants in the chain are somehow related. (For some other kinds of features, matching values of network=* can also serve this purpose.)
- An apartment complex should consist of multiple building=apartments areas and other features within a landuse=residential residential=apartments area. Even if each building happens to share the same building=* value, it is not thought of as one building overall.
If two features are far apart, such as in different towns, it is very unlikely that they share a common identity or belong to the same site.
In February 2010, over 41,000 site relations tagged site=stop_area were imported to represent public transportation features in Germany, with the source tag "naptan_import". Such public transportation stop area features are now more commonly tagged as type=public_transport relations plus public_transport=stop_area. As of 2021, these relations account for 26% of all site relations worldwide.
In March 2010, over 72,000 site relations tagged site=geodesic were imported from the source "©IGN 2010 dans le cadre de la cartographie réglementaire" in France to relate groups of man_made=survey_point features. As of 2021, these relations account for 46% of all site relations worldwide.
|Dispersed facilities power plants like wind, tidal and photovoltaic power plants.||type=site
|up to 3164 (2020)|
|Parking sites - useful for cases where parking entrances are mapped but parking area is not yet mapped. Once parking is mapped as an area with service roads marked site relation is no longer useful and may be safely deleted.||type=site
Historical Objects Map
|at most ~1000 (2015-08)|
Historical Objects Map
|at most ~3800 (2015-08)|
|French survey point site (IGN import)||type=site