Relation:site

A site relation is used to group objects which have a common identity but discontiguous geometry, i.e. distributed over a (relatively small) area. It is appropriate when a single real-world feature, with a common name and other common characteristics, cannot be accurately represented by an area or a multipolygon, since it incorporates one or more point or linear features.

For example, wind farms consist of multiple wind turbines (tagged as nodes) spread over a large area of unrelated farmland or other landuse.

Site relations have limited support among data consumers, so consider if your use can be better served by alternatives.

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. For example, amenity=university, amenity=parking, power=plant. The tag site=* may be used to further specify the kind of site. Values in use include site=geodesic, site=stop_area, site=parking, site=wind_farm, site=mall, site=piste.

Add all other necessary tags (name=*, operator=*, website=*...) to the relation to map its characteristics.

Finally, add members, which may be nodes, closed ways or open ways. The members are added without having to specify a role apart from perimeter.

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.

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

Renderers

Renderers which support site relations include:

• OpenCampingMap which takes site relations into account when showing camp-site features
• Open Infrastructure Map, which renders power plants tagged as site relations
• OpenSnowMap [1]

Geocoders

• OpenHistoricalMap's Nominatim instance indexes site relations. [2]

Alternatives

There is no need to create a site relation for everything that may be called a "site" in English. For areas ("sites") with well-defined boundaries, data consumers rely on spatial queries to automatically infer that something lies within the area:

• 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.
• 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, those areas can be grouped in a multipolygon relation rather than a site. For example, if a single school campus actually consists of multiple discontiguous sections, map each section as a closed way with outer of a multipolygon relation tagged amenity=school. However, that is only possible if the members have the same feature tag; if, for example, a heritage site consists of a palace, a park and a vineyard at different locations, you must tag each of those features appropriately (historic=castle etc.) and group them in a site rather than a multipolygon.

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 power plants like wind, tidal and photovoltaic power plants.	type=site + power=plant	~11500 (2026-06)	Høg-Jæren Energipark Høg-Jæren Energipark
Parking sites – useful for parking entrances where the parking area is underground or is not mapped yet. If the parking is mapped as an area with service roads marked, site relation is not 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=*	~4250 (2026-06)	Weißenhofsiedlung Weißenhofsiedlung
Historic site Historical Objects Map	type=site + historic=*	~2400 (2026-06)	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
• Relation:provides_feature