Proposal:Power plant parts
| Power plant parts | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Russss |
| Tagging: | power=plant_part |
| Statistics: |
|
| Rendered as: | Likely not visible on standard maps, will be rendered on OpenInfraMap |
| Draft started: | 2021-10-10 |
Some power plants, particularly larger renewable plants, are constructed in multiple phases. For a number of reasons, it may be useful to record the details of these separate parts in OpenStreetMap, but the distinction between these parts is often not obvious to observers on the ground and is of limited use to most data consumers.
A new tag, power=plant_part, is proposed to provide a standard way for these parts to be tagged where necessary, without complicating higher-level use of the power network data.
Rationale
Large power plants are tagged in OSM using the power=plant tag, usually either as an area or as a relation (in the case of dispersed plants such as wind farms).
Many large plants - wind farms in particular - are constructed in multiple phases. Operators of the plant may continue to refer to it as separate parts (for example "phase 1", "phase 2"), but this a technical distinction which is often not clear on the ground. When mapped in OSM these parts can result in a number of adjacent power plants which are identical in terms of operator=*, plant:source=*, and plant:method=*.
Data consumption
The lack of clarity in OSM over this distinction has resulted in some power plants being mapped with overlapping power=plant objects: one object representing the entire power plant, and smaller objects representing the separate phases. This is a violation of One feature, one OSM element, and is harmful for power data consumers as it is complex to detect that these objects represent overlapping parts of the same plant. A consumer summing the plant:output:electricity=* values of these plant objects would over-count the output of the power plant by a factor of two.
A data consumer who is not specifically interested in power infrastructure may want to render power plants for informational value. The distinction between "phase 1" and "phase 2a" of the same wind farm is likely to be unwanted jargon to this consumer. A standardised way of representing this separately in OSM will also improve the usefulness of the data for general purpose consumers.
Data import and reconciliation
A large amount of open data is available on renewable power plants, for example the UK's Renewable Energy Planning Database and the U.S. Wind Turbine Database. These data sources frequently represent multiple phases of a power plant project separately. When reconciling OSM with these external data sources, it is convenient to have a 1:1 linkage between OSM objects and objects in the external database.
The tag values (such as plant:output:electricity=*) on the plant_part object can then be directly compared with the values in the external database. The data within OSM may then be validated to check that the values tagged on the plant are consistent with those tagged on its constituent plant_parts.
Tagging
A new power=plant_part tag should be created. To reduce duplication of keys, it is proposed that this should use the existing secondary keys (for example plant:source=* and plant:output:electricity=*) from plant. It seems unnecessary to create a parallel schema of tags such as plant_part:source=* when the context can be easily determined from the primary power=* tag.
The power=plant page should make clear that each power=generator should be be represented by no more than one power=plant object.
In a conventional power plant, tagged as an area, the parts can also be mapped as areas, as geographic querying should be sufficient to identify the relationship between a plant and its constituent parts.
In dispersed power plants
Some plants, particularly onshore wind farms where the landuse between turbines is unrelated to the wind farm, are tagged as relations with type=site in accordance with the guidance for dispersed power plants.
The most "correct" approach to tagging plant parts in this situation would be to use nested relations, where the power=plant relation is the parent and the plant parts are child relations. The plant parts would in turn contain the generators.
The nested relation approach would likely represent a breaking change to power data consumers, and nested relations are not currently widely supported among OSM processing software. It is proposed that nested relations of this type are explicitly discouraged, and that plant parts are tagged as independent relations with type=site. This should be reconsidered if/when support for nested relations improves.
Tag naming considerations
An analogous existing tag is building:part=*. However, this is a top level tag, and does not translate well to this situation (power:part=plant seems less obvious in meaning). Using a colon delimiter in tag values is uncommon, and so I also consider power=plant:part to be less obvious.
power=plant_part seems like the most straightforward/least worst option here, however I am open to suggestions.
Examples
Black Law Wind Farm (2321400
2321400, OpenInfraMap) is an onshore wind farm near Glasgow, Scotland which was built in two phases. It has a single Wikipedia article (and hence Wikidata entry), but continues to be referred to by its operator as two parts (Black Law Windfarm and Black Law Windfarm Extension). It is currently tagged as a single relation in OSM, with some information about the phases contained in the notes tag.
Gunfleet Sands Wind Farm (293260 293260, OpenInfraMap) is an offshore wind farm off the Thames Estuary. It is again considered as a single plant by Wikipedia, but it is made up of three phases. The individual phases are currently tagged as power=plant areas, which are members of a power=plant relation. This situation illustrates the duplication issue, where a naive consumer will end up unknowingly double-counting the plant's capacity.