Relation:site

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 allows representation of a single discontiguous geometry, as opposed to an organizational relationship or a spatial relationship that is merely a coincidence.

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 or multiple areas forming a multipolygon, since it incorporates one or more point or linear features. A typical example is a  wind farm, which consists of multiple wind turbines and a substation that connects them to the grid, but spread over a large extent of farmland unrelated with the wind farm operator.

Site relations have poor support among data consumers, so consider better supported alternatives for what you are trying to map.

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:

• name=*
• etc.

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.

Software support

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 labelled on a map or listed in search results.

Renderers which support site relations include:

• OpenCampingMap which takes site relations into acount when showing camp-site features
• OpenInfraMap, which renders power plants tagged as site relations
• OpenSnowMap [1]

By contrast, multipolygons are more intuitive and enjoy widespread software support.

Alternatives

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.

History

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.

Examples

Feature	Tag	Statistics	Example
Dispersed facilities power plants like wind, tidal and photovoltaic power plants.	type=site + power=plant	up to 8136 (2023)	Høg-Jæren Energipark Høg-Jæren Energipark
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 + site=parking		Parkhaus Liederhalle/Bosch-Areal Parkhaus Liederhalle/Bosch-Areal
Heritage site Historical Objects Map	type=site + heritage=*	at most ~1000 (2015-08)	Weißenhofsiedlung Weißenhofsiedlung
Historic site Historical Objects Map	type=site + historic=*	at most ~3800 (2015-08)	Festung Torgau Festung Torgau
Historic site Historical Objects Map	type=site + historic:civilization=*		Bend of the Boyne Bend of the Boyne
French survey point site (IGN import)	type=site + site=geodesic		Le Bélieu I Le Bélieu I

See also

• type=multipolygon
• Relation:multilinestring – similar to site relation but only for ways
• Proposal:Site – the main proposal page for this feature
• Proposal:Site Perimeter – a sub-proposal for members with a 'perimeter' role
• Proposal:Group Relation