Refinement of power generation for the next decade

General talk Tagging general discussion
,
1

Hello everyone,

OpenStreetMap already supports many power generation features and usage of existing tagging recently surged a bit (1M to 5M for power=generator between 2020 and 2025).
This tagging has been reviewed 12 years ago and some technologies or practices evolution encourage to update it (power storage, new technologies, chaining…). Let’s introduce the Power generation and storage proposal as an attempt for a future proof refinement that got @map-dynartio and I busy along the MapYourGrid initiative:

Nothing is perfect and many discussions already asked for something of this kind. I particularly remember this SOTM 2022 presentation by @Richard.
We started from generator:type=solar_photovoltaic_panel and came to the conclusion replacing it will already impact 80% of existing features.

The most important parts are the Rationale general reasoning, the tagging tables and the examples.
For those who wants to learn more about the logic behind, this appendix give details for each power source.

As to ease review we propose this optional poll as guide through different points. It doesn’t act as a vote and the result will help to improve the document along the RFC.

Power generation is an industrial field with a broad diversity of technologies. It’s hard to refine osm tagging for a specific one without disturbing the whole practice. So I chose the strategy of a large refinement as a tradeoff between breaking changes and lower the disturbance on existing features by making one single edit instead of many.
It’s also challenging to set a limit between what is relevant for OpenStreetMap and other databases, including Wikidata.

This review is intended to find consensus on appropriate tagging and nothing should occur on database after voting. Time will come about necessary replacement plan depending on what we will agree on, as per Automated edits code of conduct.

Best regards

7 Likes
MapYourGrid webinar on data quality for power grids data
OSM definition of power generator vs. power plant?
Wärmepumpe korrekt erfassen
2

What a big work ! The proposal seems very good to me !

As an occasional power stuff mapper, I have always had difficulty understanding the tags on energy-related objects, I used to just copy and paste (like for this node : Node: 10303392425 | OpenStreetMap).

Now I see that the suggestions — especially with suffix :method, :technology, :source — would allow me to understand and add thoses informations more easily.

1 Like
3

Impressive work without doubt. I fully agree that tagging of power plants and generators would surely profit from refinement. The only problem I see that this is such a complex issue that most mappers will be overstrained whith the details.

I have not yet taken time to study the full proposal, just noted that some of the example plants/generators (like hydro and solar) do not have any input value at all. Probably by intention but it creates the impression as if something is missing there.

Anyhow great job, well done.

2 Likes
4

Hello @Map_HeRo @Koreller and thank you for comments, so quick

That may look really complex and hope it’s clear the proposal puts more items as optional than currently, as to focus on the most important part: power plants.

At this stage of the RFC, it is done on purpose.

We seek for the minimalist tagging solution and obvious inputs like water for hydro power or sun for solar generation are not needed. We don’t have any figures to put in the input:* so yes will pretty always be the only value and doesn’t bring more information than the :source key.

It’s not wrong to add them but it’s redundant.

2 Likes
5

Hi, i map power infrastructure (among other things) and have been a part of the MapYourGrid team since the beginning of this year. I’ve helped draft the new refinement proposal, alongside @InfosReseaux. It’s been a real labour of love, but somewhere along the way, the proposal became a tiny bit long. Of course, not everyone has the time or energy to read it all, so to walk you through the main ideas, here is a short-ish 3 minute video : 20251203 Power generation and storage proposal video.mp4 - Nextcloud

3 Likes
6

Hello!

I’ve added a list to be completed of impacted software that involve power=plant or power=generator or both.

It gives an idea of the necessary actions to take on corresponding projects in case of success of the proposal.

Being in the list doesn’t actually mean an action is needed. OSM carto for instance only involves power=plant, power=generator and generator:source=wind which aren’t changed.

I particularly wonder if following projects are relying on generator:method or generator:type:

Feel free to complete the table or raise concerns here if you are aware of something missing.

7

I have had a closer look at your comprehensive proposal and (although being far from an expert) want to add some thoughts.

  1. General definition

In commmon language power generators and plants are designed to produce electric energy and, as a side effect, hot water in some cases. We are using these terms in a much wider range which is fine, but there are some edgy cases where I am in doubt. Calling a unit providing hot water by burning gas or using electricity a generator seems quite far streched to me. I would call those rather a boiler.

  1. Energy from the grid

For electric power obtained from the grid you propose grid as source which makes sense as one cannot specify from which primary source the power has been generated.

What about gas obained from the gas grid by gas power plants? No way to specify if the source of this gas is fossile or bioenergy. It’s a mix, same as with electric power.

Similarly the diesel combusted by a diesel generator can contain fossile diesel as well as biodiesel.

  1. Heat pumps (see: Wärmepumpe korrekt erfassen)

It has been stated already that a heat pump is not a generator and does not transform energy. Anyhow a heat pump plant may provide large quantities of hot water for industrial or residential purposes like a steam turbine plant does, so I think using power=plant and power=generator appears to be acceptable.

Questionable is the use of source, input and output as a heat pump does not transform anything. In fact input and output are both “temperature” and one cannot even say that one side is higher temperature than the other one as a heat pump works in both directions. Maybe it would be more appropriate to skip those tags for heat pumps and add heat_pump:type or heat_pump:technology instead?

At present there are very few large heat pumps easily identifyable on the ground by their physical setup. By far most heat pumps are small indoor aggregates not visible and in most cases not accessible for a visitor. What one can see in increasing quantities are the outdoor units of air-water-heatpumps used for domestic or retail buildings as discussed in the above linked topic.

Any idea how to integrate these into the generator scheme? Although commonly called “heat pump” in fact these units are merely heat exchangers. Maybe we should have a specific tag for them like power=heat_exchanger?

  1. Biogas Plants

I have mapped some biogas plants and found it nearly impossible to identify the different units being part of such a plant. A biogas plant may comprise the elements

  • pre-digester to prepare the biomass for the digester
  • digester to produce biogas from biomass
  • post-digester for further treatment of the biomass
  • storage tank for the fermentation residues

plus 1 or more of the elements

  • gas storage tank
  • gas cleaning unit to allow feeding biogas into the gas grid
  • 1 or more combined heat and power generators using the biogas as fuel

Most biogas plants are not accessible to visitors and part of the elements cannot be clearly identified on aerial imagery in most cases, so one can only map the plant as a whole. By doing so you will get a mess of source, input and output values because 2 completely different generator systems are working in 1 plant. Any idea how to address this problem?

  1. Modern waste power plants

Modern waste recycling plants do much more than just gasify or burn waste. There are plants using general waste as well as biomass to produce biogas. The solid residues are further recycled into solid fuel, mineral waste and a very small fraction of completely useless waste. The biogas is combusted to produce power and hot water. Additionally the plant may feed biogas into the gas grid if there is an exess or, if production is too low, use mineral oil as additional fuel.

So we would have biomass, waste and fossile fuel as source, biogas + solid fuel as output step 1 and electricity + heat as output step 2. As a side effect there is also some minor output of mineral fertilizer. How to tag such a plant if you do not have access to identify the different units and tag them one by one?

1 Like
8

No you haven’t.

In addition to that, what is written in the proposal at a high level completely fails to describe what you are trying to do or why you are trying to do it. It contains things like:

the deprecation of plant:method=barrage in favor of plant:method=water_storage;

and

the deprecation of `plant:method=photovoltaic` in favor of `plant:method=photovoltaics`;

which just look like mindless tagfiddling.

It also contains gems such as:

plant:method=resistive & generator:method=resistive 	A plant or generator that produces heat directly from electrical resistance (resistive heating).

Are you really trying to say that a one-bar electric fire (or similar technology, scaled up) is a “power plant”? What it actually does is turn electrical energy into heat; in no sense does it fit any normal definition of “power plant”. I genuinely can’t tell whether the inclusion of this here is a joke designed to detect if people are actually reading the 1000-or-so lines “proposal” or if you are serious.

What I would suggest instead is:

  • Throw away this proposal as it stands.
  • Instead, think about the things that existing tagging schemes can’t currently capture, and how to extend them to capture that information, without changing any existing tags.
  • Think of how that information can be observed by the average OSMer from the roadside.
  • If it can’t be observed by the average OSMer from the roadside, it probably doesn’t belong in OSM.
  • If you have a business or project that needs information beyond that, then you probably need your own database.
1 Like
9

@InfosReseaux What would be the correct tagging for such?

P2H-Boiler
P2H-Boiler640×640 28.4 KB

I mapped it and put on the tags. This already seems to call for four (4) wizards. Would there be a fifth one?

PS: storage_tanke:type=boiler + boiler:method:electricity=yes + boiler:method:biomass=yes might be worth adding? Also adding electricity:method=resistive I’d say overshoots, as well as biomass:method=combustion would.

10

Hello and thank you for your comments. I will try to answer in the most concise way as possible and maybe change the necessary in the proposal directly.

Yes, I second these doubts and I came to the need to extend this definition following the increasing interconnection between electricity generation and by-products. It’s still possible to refine proposed tagging but I also wanted first of all to avoid falling back to man_made=boiler for instance. Should we move power=generator to (or solely introduce for anything but electricity) energy=converter and power=plant to (or solely introduce for anything but electricity) energy=plant or something?

This point is relevant and there is probably an inconsistency between grid/electricity and (fossil or bioenergy)/gas.

Can’t we consider gas obtained from pipelines is merely fossil, despite mixed with locally produced biogas?
If not, I don’t see any valid solution for now to combine “mixed fuel from pipelines” and “fossil” classification.

Depending on how the opportunity to work with energy=converter or another energy=* feature, it would be great to have heat pumps part of it.

I found out we missed a proper technology for heat exchanges in this example

I also would like to mark a strong difference between actual heat pumps (with compression), with generator:technology=heat_pump and another technology for passive exchanges. A suitable opportunity may rise out of energy=* as it doesn’t have anything to do with electricity.

I share the struggle about biogas plants and the difficulty to describe different components. It’s the same for wastewater treatment plants or other plants involving several steps.

The only generator I see in the process is the digester. Other parts may be other machines but aren’t directly involved in the energy conversion process. We may need a Biogas plants proposal to define these other machines. Currently, just map the plants as a whole power=plant and find the digester if you can.

I think the Stuttgart-Münster example illustrates exactly this situation. The proposal aims to cover the chaining of several steps in a more complex process. It’s not perfect but that’s the direction I want to follow to describe it all.

11

Hello @Hungerburg

I miss some details about this device to give you the tagging. I understand it’s a tank storing 1400 m3 of water, heating it with the help of a resistor and store the heat. The electricity that heats the water comes from the combustion of some biogas produced locally. Is it right?

This option is not properly covered by the proposal indeed, since the generator:source=bioenergy doesn’t contains anything driven by electricity. I will take care of this possibility to continue working on this possibly with energy=converter.

12

What do you mean? There is actually a table to be completed in the proposal.

The proposal design started with the need to refine generator:type=solar_photovoltaic_panel for reasons that has been given at SOTM2022 presentation, which corresponds to ~80% of existing power=generator features. At that point, rewording generator:method=photovoltaic into `generator:method=photovoltaics` (because the last is the correct syntax) is likely to be done in the same time.

No, just like a standalone solar panel on a house’s roof is not a power plant. It’s already an established practice in OSM, we don’t map any small generator as a power plant.

Otherwise, there are actual plants that involve industrial electric boilers and those industrial facilities are targeted with proposed tagging you mention.

That’s precisely what we are doing here. The proposal will probably be changed according to what we find. That’s undergoing work in which we need to document and find consistent solutions about undergoing transitions.

13

Alas, you don’t seem to have succeeded.

You clearly have a very in-depth vision of how you would like energy infrastructure to be classified. That may or may not be relevant to OSM (based on “verifiability”).

Please, take a step back and don’t try and reinvent everything.

If you don’t and try and persist with this you risk making energy infrastructure data in OSM unusable, because it will become a mixture of current tags and your suggestions, some of which are a blatant misuse of actual words (electric fires as “generators” previously, heat pumps just now).

14

This risk has been clearly identified and that’s not my goal. Those 5 lines in the document explains why a global reasoning on tagging is relevant and how changes will be done after the vote.

Changes should be done with appropriate edits, following automated edits code of conduct to avoid as much as possible situations of mixture tagging.

Prior to this, and because power generation tagging involves linked or nested keys, it’s important to get the big picture of what’s needed and what’s not. Everything in this proposal is surveyable or observable in public information around power generation facilities. We don’t plan nor encourage to import anything at all.

15

The part of your “proposal” that you link to does not address that risk at all. It merely says that there will be no “mechanical edit”. That also means (like riverbank, which you mention) that consumers will need to handle both current and your proposed tags if they are handling data from everywhere.

16

Quote from the document: To be clear, no immediate edits will occur upon approval. The vote simply validates the tagging model. We think that such changes should then be rolled out following an automated edit process, with a clear plan to be developed afterwards.

That’s why I started to list impacted software, to state who needs to adapt and how, as to provide the most suitable transition plan when an agreement will be found on the tagging.

17

To be clear, I’ve voted your post down because what you have written in response to the problem that I stated does not in any way address that problem. If complete (and please follow my links above to add more) it would describe software that would need to change to process your newly proposed tags. As long as there are some of the current tags in the database, software will need to handle both sets for global coverage (like with riverbank).

18

The proposal is quite large, which makes it a bit hard to understand all its impacts. It seems to be coherent and I can’t spot any obvious problems.

I’m not fully sure if all the changes of tags (e.g. generator:type to generator:technology or photovoltaic to photovoltaics) are really necessary - maybe we should avoid them.

What I’m missing is an analysis if there are any conflicts with the old scheme. I.e. is there any tag that has a different meaning in the old and new scheme? This would be a potential show stopper.

1 Like
19

Once time will have come, transition to be discussed should replace existing tagging at an acceptable pace for software to switch according to their constraints.

Do you maintain software that currently use plant:source , plant:method, plant:output, generator:method, generator:type, generator:plant or generator:output which could be impacted with such a change?

I would not have proposed these changes on their own.

The fact is we are about to retag 80% of power generators, to abandon generator:type=solar_photovoltaic_panel and it’s an opportunity to clean things up in the same time.

I don’t think so and I would avoid it too. So if we find such problem, it’s open to improve.

The global reasoning fits in this chart: File:PPGSP General reasoning illustration.svg - OpenStreetMap Wiki

20

Rationale has a looooot of text, but within first few screens I see no clear benefits.

Maybe at least give some examples at beginning that will describe how something surveyable can now be tagged and could not be tagged before?
And requires such enormous proposal?

Surely some specific examples can be found?

1 Like