Skip to content

Navigation Menu

Sign in
Sign up

Bring tabula-calculator-calcsetbuilding data back - #2285

Open
yerbol-akhmetov wants to merge 14 commits into
PyPSA:master from
yerbol-akhmetov:fix/tabula_return
Open

Bring tabula-calculator-calcsetbuilding data back #2285
yerbol-akhmetov wants to merge 14 commits into
PyPSA:master from
yerbol-akhmetov:fix/tabula_return

Conversation

@yerbol-akhmetov

@yerbol-akhmetov yerbol-akhmetov commented Sep 3, 2026
edited
Loading

Copy link
Copy Markdown
Contributor

Closes #2281 .

Changes proposed in this Pull Request

Good day, PyPSA-Eur community. This PR aims to bring tabula-calculator-calcsetbuilding back, because it is required for build_retro_cost rule. The data is retrieved from original source of https://episcope.eu/fileadmin/tabula/public/calc/tabula-calculator.xlsx as an Excel file. Rule retrieve_tabula_calcsetbuilding retrieves the Excel file and prepares CSV format by slicing the Calc.Set.Building sheet. The source is set as primary. It would be good to mirror it as archive to https://data.pypsa.org/.

What do you think about the PR, @fneum, @euronion, @lisazeyen, @lkstrp ? Could you please review it?

Checklist

Required:

  • Changes are tested locally and behave as expected.
  • Code and workflow changes are documented.
  • A release note entry is added to doc/release_notes.md.
  • The description is human-written and any AI-generated content is marked.

If applicable:

  • Changes in configuration options are reflected in scripts/lib/validation.
  • For new data sources or versions, these instructions have been followed.
  • New rules are documented in the appropriate doc/*.md files.

yerbol-akhmetov marked this pull request as ready for review September 3, 2026 11:12
euronion self-requested a review September 3, 2026 13:52

euronion commented Sep 3, 2026

Copy link
Copy Markdown
Collaborator

Thanks @yerbol-akhmetov !

I took the liberty of directly committing onto the branch a simplification - inlining the retrieve logic and reading the xlsx file directly rather than writing an intermediary csv file.

Two reasons for doing it this way:

  1. We want to only have the original data in the data/ subdirectoy, not parsed or modified (like your csv file) data
  2. The retrieve functionality can be simplified and the intermediary csv doesn't really seem necessary. Now the logic is similar to the boilerplate code for the other rules.

Can you test whether the small changes of using the xlsx file directly work and do not cause deviations compared to using the csv file?

Are you fine with this change? Else we can revert my commit.

yerbol-akhmetov reacted with thumbs up emoji

Copy link
Copy Markdown
Contributor Author

Thanks @yerbol-akhmetov !

I took the liberty of directly committing onto the branch a simplification - inlining the retrieve logic and reading the xlsx file directly rather than writing an intermediary csv file.

Two reasons for doing it this way:

  1. We want to only have the original data in the data/ subdirectoy, not parsed or modified (like your csv file) data
  2. The retrieve functionality can be simplified and the intermediary csv doesn't really seem necessary. Now the logic is similar to the boilerplate code for the other rules.

Can you test whether the small changes of using the xlsx file directly work and do not cause deviations compared to using the csv file?

Are you fine with this change? Else we can revert my commit.

Hi, @euronion. Thank you for the improvements. I am totally fine with it.

@euronion euronion left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, two more minor changes, please double check.

As soon as you confirm @yerbol-akhmetov that my changes didn't change the logic, @lkstrp and I will create the archive and then we can merge 💪

yerbol-akhmetov reacted with thumbs up emoji
Comment thread data/versions.csv
Comment thread doc/data_inventory.csv Outdated
Co-authored-by: Johannes HAMPP <42553970+euronion@users.noreply.github.com>

Copy link
Copy Markdown
Contributor Author

Hi, @euronion. Regarding two suggestions, all good from my side. It did not change the logic. I was thinking if we could set retro_endogen: true for one of the CI tests (e.g. overnight one), so that we will not miss updating and testing retrofitting scripts. What do you think? Can we implement it in one of the future PRs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@euronion euronion Awaiting requested review from euronion

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Missing tabula data

AltStyle によって変換されたページ (->オリジナル) /