Skip to content

MaStR source pinned to 2025-02-09 Zenodo dump; loader hardcodes that date in the zip path #299

Description

@MaykThewessen

Summary

The MaStR data source is frozen to a single Zenodo release, and the loader additionally hardcodes that release's date inside the zip, so even bumping the config to a newer dump is not enough to make it load.

1. The source is pinned to one Zenodo dump

config.yaml pins:

MASTR:
  fn: bnetza_open_mastr_2025-02-09.zip
  url: https://zenodo.org/records/14783581/files/bnetza_open_mastr_2025-02-09.zip

German plant data therefore only refreshes when a new dump is published to Zenodo, which happens infrequently. Between releases every powerplantmatching user gets stale German generation/capacity, with no in-library way to use a more recent Marktstammdatenregister export.

2. The loader hardcodes the dump's internal folder date

In MASTR() (data.py ~L2411) the storage-units CSV is read from a fully hardcoded path that embeds the release date:

fn_storage_units = (
    "bnetza_open_mastr_2025-02-09/bnetza_mastr_storage_units_raw.csv"
)
storage_units = pd.read_csv(file.open(fn_storage_units), usecols=cols)

The moment MASTR.fn/url is bumped to a newer dump (whose inner folder is bnetza_open_mastr_<newer-date>/), this read fails with a KeyError. So updating the config alone is not sufficient; a code edit is required for every new release.

A related schema drift: ThermischeNutzleistung is present in the Zenodo CSV dump but absent from the open_mastr bulk export, so any non-Zenodo-shaped dump also breaks the CHP-detection assign that references that column.

Proposed fixes

  1. Date-agnostic inner path. Match the storage-units CSV by suffix (name.endswith("bnetza_mastr_storage_units_raw.csv")) instead of a hardcoded dated folder, so any dated dump loads unchanged.
  2. Schema-tolerant CHP detection. Fall back to KwkMastrNummer alone when ThermischeNutzleistung is absent.
  3. Glob-capable fn. Allow MASTR.fn to be a glob (bnetza_open_mastr_*.zip) so a locally built, dated dump is auto-selected (newest wins; ISO dates sort chronologically), with the frozen Zenodo url kept only as a download seed.

Items 1-3 are small and behavior-preserving on the current Zenodo dump. I have these working locally and will open a PR. A fourth, optional piece (a helper script that rebuilds a current dump from the open_mastr bulk export, decoupling freshness from the Zenodo cadence) can follow separately if there is interest.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions