Proposal talk:Power generation storage

From OpenStreetMap Wiki
Jump to navigation Jump to search

Comparison

*:technology=* is Still too vague and broad. Doesn't improve it to offer significant benefit to worth renaming, which will be opposed for effort and disruption to not break existing applications. I have these ideas to distinguish different aspects, especially to separate nuclear reactor design, family, and iteration. Proposal:Alternative_energy_focused_power_revamp#Specific_keys —— Kovposch (talk) 08:02, 10 November 2025 (UTC)

It depends on where we start. The most prominent thing we want to fix is current generator:type=solar_photovoltaic_panel which changes into generator:source=solar + generator:method=photovoltaics + optional generator:technology=* if applicable.
Could we find a better term than mechanism to deal with chemical processes and better than architecture to deal with turbines shape?
Somehow, generator:technology=* could be a bridge toward more detailed wikidata knowledge regarding some non-geographic criteria Fanfouer (talk) 15:23, 11 November 2025 (UTC)
I thought about *:mechanism=* and *:architecture=* simply to follow the existing format, where they are used for all energy sources. Are you asking about separating into different attributes for different energy sources, or only better naming to cover both nuclear vs chemistry or turbines? The latter seems tricky. I can try to think about it.
—— Kovposch (talk) 10:36, 12 November 2025 (UTC)
I agree with you it is tricky to find attribute suitable for all energy sources. I indeed prefer finding a common attribute that better fit to all energy sources and don't separate between sources. If we don't manage to find one, I would prefer fallback on wikidata with way more elaborated ontology as to keep OSM tagging simple Fanfouer (talk) 10:06, 13 November 2025 (UTC)

Related tasks

Not exactly related, but the opportunity should be taken to clean up generator:type=* vals

  • *=cold_fusion : Not scientifically proven and relevant in the foreseeable future
  • *=combined_cycle should be its own attribute as it's not a "generator" itself. There are different combined cycles, as well as other additions (eg preheating, reheating, heat recovery).
  • *=boiler : Seems a purpose for *:output=hot_water + *=main , and not a "technology" either. In common language, it contrasts electricity "generator" to be for heating.


—— Kovposch (talk) 08:02, 10 November 2025 (UTC)

We will consider doing a little more clean up in generator:technology=* indeed. Regarding combined_cycle, it's difficult to remove as someone may not be knowledgeable enough to distinguish gas turbine and steam turbine in those facilities but keep willing to map a generator. It's necessary to maintain a very low level of difficulty even temporary as to allow anyone else to refine and split into two actual generators afterwards. Fanfouer (talk) 15:17, 11 November 2025 (UTC)
Can't it be *=gas_turbine;steam_turbine , as that's what being done, and it can be split into 2 power=generator ? How to relate them together? To solve this, what I meant is *=combined_cycle can be some *=combined to distinguish *=open cycle ones.
—— Kovposch (talk) 10:32, 12 November 2025 (UTC)
We want to avoid lists as much as possible and even generator:technology=combined_cycle is imperfect, it would mean the same as *=gas_turbine;steam_turbine in a more simple fashion. By the way, combined and open cycles look more like a plant's property than the generator, aren't you? Fanfouer (talk) 10:42, 25 November 2025 (UTC)

Organizing, formatting, naming

No, we aim at the opposite: replacing generator:output=* and plant:output=* with output=* and bring generic input and output substances. Generator and plant suffixes don't bring anything relevant here. Fanfouer (talk) 15:13, 11 November 2025 (UTC)
But there's no other reason to change *:output=* ? It can be kept unchanged. Let *:input=* follow it.
—— Kovposch (talk) 10:12, 12 November 2025 (UTC)
Existing generator:output:*=* currently prevents to reuse clear generic concept elsewhere for no reason. As we plan to change generator:type=solar_photovoltaic_panel, we should refine the whole tagging as to reduce the amount of edits to be made now Fanfouer (talk) 11:05, 12 November 2025 (UTC)
Now I see it seems to hint at use in refineries, chemicals, and other industries. But this needs much more thinking. The items immediately encounter consistency problems across fuel:*=* , content=* , and substance=* for different features. input:uranium=* isn't the only nuclear fission fuel, with at least MOx, and doesn't consider fusion at least for research.
Besides, input:*=* doesn't necessarily suggest it's for the "fuels". Air is used for combusting, and cooling vs water.
—— Kovposch (talk) 07:38, 13 November 2025 (UTC)
Well, as generator:input=* and input=* are both extendable keys and offer the opportunity to combine input:uranium=* and input:water=* both for fuel and coolant if mappers want to, it's less important to give that focus in particular. From that perspective, input=* doesn't bring less nor more than generator:input=*. We could propose input:fuel:*=* or input:coolant:*=* for instance but would input:fuel:electricity=* be consistent? The idea to contextualize input with their usage is interesting and we should be careful to not complicate it too much Fanfouer (talk) 09:02, 13 November 2025 (UTC)
Stage won't be suitable here, the definition for generator=* is a more broader role, including auxiliaries that isn't a stage in the process. It's consistent with transformer=* and switch=*. It comes in replacement of generator:plant=* which could be preserved but it doesn't look necessary to me.
We could also consider generator=standalone when not involved in a plant. Fanfouer (talk) 15:13, 11 November 2025 (UTC)
That's not the only possibility I can see. generator:plant=* at least tries to say it's what the power=generator is doing inside a power=plant . generator=* could be used more defining characteristics, or other attributes that can't be named properly (yet).
  1. Baseload vs load-following vs peaker
  2. Off-grid vs on-grid (especially about own use, and microgrids)
  3. Single-building vs site vs district vs other boilers
  4. Emergency generators.
I looked power=plant at the same time. As there's substation=traction , how to show Traction_powerstation on Wikipedia (there are at least 2 more active in Japan)?
—— Kovposch (talk) 10:24, 12 November 2025 (UTC)
generator=backup could also be another relevant value. We could refine generator=standalone to better describe if it's on-grid or offgrid if possible. But we should keep this neat and refrain from using namespace when it's not needed. Some properties may be discussed after this already big proposal, once the framework would have been refined. Fanfouer (talk) 11:05, 12 November 2025 (UTC)
  • plant:source=p2x : I don't understand why *=p2x belongs to plant:source=* , when you have already distinguished energy source and carrier. P2X is furthermore a purpose or conversion, not a "source". —— Kovposch (talk) 08:02, 10 November 2025 (UTC)
It has already been replaced by plant:source=grid since p2x is indeed a process and not the best choice Fanfouer (talk) 15:13, 11 November 2025 (UTC)
That's an interesting choice. Have to think about it.
—— Kovposch (talk) 10:12, 12 November 2025 (UTC)

Scoping

The proposal is very long. I suggest to not be too detailed for existing vals (eg Proposal:Power_generation_storage#Technologies_associated_to_the_turbine_method) to avoid confusion, which can be moved to a subpage to explain them (ie for what different turbines are used for) if needed. Furthermore, entirely new and independent (not affecting other tagging) vals eg for wave power can be split off to another proposal, keeping this here focused about storage and restructuring.
—— Kovposch (talk) 10:43, 12 November 2025 (UTC)

The document has been split with new appendix to make the main one shorter. Hope it helps Fanfouer (talk) 11:21, 19 November 2025 (UTC)

Gasifications, fluid conversions

generator:method=gasification + currently generator:technology=gasifier doesn't seem helpful, resulting in it being optional. *=gasifier can be changed to the actual types of gasifications/gasifiers, including plasma gasifier, and fludized-bed reactor. Maybe same for generator:technology=bioreactor , although it's an existing val.
Other generator:source=fossil have only generator:method=combustion , but they can be produce syngases, and then other gas-to-liquid, synthetic liquid fuels. On top of needing other generator:method=* , the generator:technology=* would become more specific similar to the above, eg *=steam_reforming somewhere.
—— Kovposch (talk) 11:10, 12 November 2025 (UTC)

Indeed, generator:technology=gasifier isn't the most useful value. As to fit in the tradeoff explained below and to preserve technology's table size, would it be acceptable to not define anything for gasifiers technologies, let a blank cell for this round and wait for a more elaborated proposal on this field? Fanfouer (talk) 10:43, 25 November 2025 (UTC)

Fuel cells, fossils, hydrogens

Originally I didn't want to mention this, but *:source=fossil doesn't have *:method=combustion only, contrary to what Proposal:Power_generation_storage#Logic_and_usage proposed or informed. They can be used in MCFC and SOFC. For reference, My ideas draft includes them. You should clarify that's only what's proposed now, not including fuel cells.
Worth noting natural hydrogen is being explored now. It's not *:source=fossil , with the serpentinization water-rock reaction (geochemical?), and natural radiolysis.
—— Kovposch (talk) 07:55, 13 November 2025 (UTC)

This is perfectly valid, the proposed model is extendable and should be completed with several proposals. The tradeoff we found to achieve this round with reasonable delays is to watch out for compatibility but refrain from including values that could be discussed in separate proposals. We probably will reduce the technology tables to fit with this strategy. Keeping only combustion for fossil source doesn't mean it's the only valid value. The list can be extended as much as possible. So we won't include fuel cells for now and this thread falls back to the other topic to evaluate the relevancy of technology vs architecture + mechanism Fanfouer (talk) 10:39, 25 November 2025 (UTC)

Waste-to-energy vs Bio vs Fossils & Rubber

Is it good to use *:source=waste for mixed (usually municipal) wastes, and *:source=bioenergy for organic wastes? What should be used for plastics or tyres only? Is the former not *:source=fossil ?
—— Kovposch (talk) 19:25, 13 November 2025 (UTC)

In the current state of the draft, *:source=waste should be used for all natures of waste (distinguished with input:*=*. Municipal waste are sometimes pre-sorted along organic, burnable and recyclable and come from precise sources Fanfouer (talk) 19:07, 16 November 2025 (UTC)
The proposal and resulting tagging seems unclear to distinguish burning of biogases from wastes (whether transported, or on-site) , vs dedicated crop biogases, vs directly incinerating wastes.
Same applies to the potential IGCC. If the user isn't familiar with the logic, it doesn't seem obvious enough plant:method=combustion may not be coal-burning directly, but have generator:method=gasification inside.
*:method=* converting wastes to liquid biofuels is missing. Then same question again.
Would plant:method=gasification;combustion be improper ? And to have plant:source=waste + input:biogas=* / input:biofuel=* when only biofuels from wastes are transported, as the received form can be distinguished between them and input:waste=* ?
—— Kovposch (talk) 14:13, 17 November 2025 (UTC)
There are two different situations in this question:
* Burning transported biogas would result in two independent facilities, one with plant:method=gasification and the last with plant:method=combustion, covered with the proposed schema
* plant:method=* is intended to document which method is involved to produce the resulting power for the plant, not all methods involved in the process. Considering plant:method=gasification;combustion is a different logic we have to think about but in general we want to avoid lists the most as possible, particularly with such values Fanfouer (talk) 10:28, 25 November 2025 (UTC)

Optional vs default

Currently this proposal uses the term "optional" for two slightly different things: tags which are low-priority or nice to have (like the generator:technology values), and tags which only have one possible value, or one very common value (such as plant:method=combustion when input:gas=yes).

I think this proposal should distinguish between these, and define a "default" value when there is only one possible value for a tag, or when one value is significantly more common than any other. In these cases, data consumers can be advised to assume the value is the default if the tag isn't present.

This will simplify tagging, but it also provides an explicit approach in case new technologies get adopted in the future, reducing the need to bulk-retag all existing items.

Russss (talk) 11:46, 10 December 2025 (UTC)

It's very relevant, thank you. Let's distinguish both, with different colours and rules. Fanfouer (talk) 18:16, 16 December 2025 (UTC)