[Option Appraisal Module] [Package 1: Measures] Split 1: Adds MeasureConfig dataclasses for serializable measure configuration.

[spjuhel]

Changes proposed in this PR:

This PR introduces a new module defining a family of dataclasses that encode adaptation measure parameters in a serializable, declarative form. This is a preparatory step for the broader Measure/MeasureSet rework.

The objective is to retain the possibility to define measures from modifiers in addition to the upcoming system that will use python functions directly, and provide a (better) user interface for this.

no existing code is changed.

New dataclasses:

• MeasureConfig top-level configuration for a single measure, aggregating all modifier configs below.
• ImpfsetModifierConfig parameters for modifying impact functions (intensity, MDD, PAA scaling, optional replacement)
• HazardModifierConfig parameters for modifying hazard (intensity scaling, frequency cutoff, optional replacement)
• ExposuresModifierConfig parameters for modifying exposures (impact function remapping, zeroing regions, optional replacement)
• CostIncomeConfig serializable representation of cost/income cash flow parameters

All configs inherit from the abstract _ModifierConfig base, which provides shared to_dict/from_dict and a __repr__ that highlights non-default fields.

MeasureConfig supports full serialization to/from dict, YAML, and legacy Excel rows (from_row), which will serve as the migration path for the existing file-based I/O in MeasureSet.

PR Author Checklist

• Read the Contribution Guide
• Correct target branch selected (if unsure, select develop)
• Descriptive pull request title added
• Source branch up-to-date with target branch
• Documentation updated
• Tests updated
• Tests passing
• No new linter issues
• Changelog updated

PR Reviewer Checklist

• Read the Contribution Guide
• CLIMADA Reviewer Checklist passed
• Tests passing
• No new linter issues

[chahank]

Excellent idea!

[spjuhel]

@chahank

Question: Should measures (defined by MeasureConfig) be specific to a hazard? (I see reasons for both yes and no)

Currently, they are specific (thus configs require you to provide haz_type).

I see how you could want modifications of impact function to be for multiple hazards
But also you should probably not be able to apply a shift in intensity for multiple hazards?

Any opinion on that?

[spjuhel]

This PR is officially open for review! Review is advised after #1274 is merged.

Actual changes to be reviewed are in:

• climada/entity/measures/measure_config.py
• climada/entity/measures/test/test_measure_config.py
• doc/user-guide/climada_measure_config.ipynb (and a few other tutos where a target was added at the top)

[chahank]

@chahank

Question: Should measures (defined by MeasureConfig) be specific to a hazard? (I see reasons for both yes and no)

Currently, they are specific (thus configs require you to provide haz_type).

I see how you could want modifications of impact function to be for multiple hazards But also you should probably not be able to apply a shift in intensity for multiple hazards?

Any opinion on that?

Good question. I would then to keep it hazard type specific. But maybe best is to ask core users of the model :).
@ChrisFairless : any opinion?