Rerunning with `extend_by_vres` results extreme overcapacity

[irm-codebase]

Version Checks (indicate both or one)

• [x] I have confirmed this bug exists on the lastest release of powerplantmatching.

• [ ] I have confirmed this bug exists on the current master branch of powerplantmatching.

Issue Description

Re-generating the collection with the extend_by_vres option produces a very high number of installed powerplants, particularly for PV and Wind.

The image below uses the default configuration (Europe). Wind is quite extreme.

For PV, I suspect the cause might be due mismatches in the coding of some technologies. Notice PV, Pv, Photovoltaics and Photovoltaics ground.

Reproducible Example

# Took 1h on my computer
import powerplantmatching as ppm

collection = ppm.collection.powerplants(
    update=True,
    extend_by_vres=True,
    fill_geopositions=True
)

stats = ppm.data.Capacity_stats()
ppm.plot.fueltype_totals_bar([collection, stats])

Expected Behavior

Two suggestions:

• A schema should be used to validate that the processed datasets conform to a given shape before they are passed to the matching algorithm. I suggest pandera.
• Consider adding some logic that 'trims' excessive capacities (when compared to annual country totals), as an optional callable function for further post-processing.

Installed Versions

0.7.1

[fneum]

We should deprecate extend_by_vres since it takes data that is not maintained anymore. We're now using GEM and MASTR for VRES mostly, which is added as regular technology (and sometimes excluded from matching).

[irm-codebase]

I'd advocate for removing it, yeah. Or at least mentioning that it is no longer maintained. Thanks for the info!

[FabianHofmann]

but shouldn't we then instead replace the old vres data by GEM data when using extend_by _vres?

[irm-codebase]

I suppose, if that's what most users would expect. I no longer use powerplantmatching in my processes, so I can no longer speak as a user unfortunately.

[fneum]

but shouldn't we then instead replace the old vres data by GEM data when using extend_by _vres?

The alternative is to remove it and always include wind and solar (which seems sensible to me).

[FabianHofmann]

The alternative is to remove it and always include wind and solar (which seems sensible to me).

ah yes, that would indeed the direct and clear way!