-
Notifications
You must be signed in to change notification settings - Fork 3
Features/#1274 unify and update to latest official open mastr #1369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Features/#1274 unify and update to latest official open mastr #1369
Conversation
…nto features/#1274-unify-and-update-to-latest-official-open_mastr
|
For eGon100RE no changes are seen in the etrago generators tables. But for eGon2035 there are differences vs the last run regarding biomass and CHPs, as can be seen in the table below that summarizes the total install capacities in DE: |
| len_old = len(units) | ||
| ts = pd.Timestamp( | ||
| config.datasets()["mastr_new"]["status2023_date_max"] | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure that we don't need that filter at all anymore?
I am just wondering if it would be needed if we want to create a status2024 scenario for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see two different cases here:
- Future scenarios: wind onshore and solar ground mounted generators benefit from the most updated available data, since those are the most possible locations for future generators.
- Status scenario: We should, as you mentioned, filter the generators by commissioning date.
I think it makes sense to import all generators for futures scenarios, and filter the generators installed after the last day of our status scenario year using this function
Does it make sense for you?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think we can do it like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| "Cloppenburg": "50643382", | ||
| } | ||
| elif ("220101" in osm_year) | ("240101" in osm_year): | ||
| elif "250101" in osm_year: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means that the branch has to be combined with the osm update, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so that means that this branch should be merged after the osm, update, right? Is that already merged?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| "Garrel/Ost": "23837631", | ||
| "Rastede": "23837631", | ||
| "Emden/Borßum": "34835258", | ||
| "Cloppenburg": "50643382", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you move this? Is it the idea that it works for osm data from 2020 and 2025?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some clarifications:
- id_bus: Contains the osm_id that are common when using OSM data from 2020 and 2025
- id_bus2: Contains all osm_id that changes between the 2 mentions OSM years
The in comparison with 2024, 5 substations change the osm_id and they had to be moved to id_bus2. I decided to do this to keep the compatibility with our last osm year, but I could adapt everything so we set that only data from osm2025 is suitable. Do you prefer to keep it like it is or change to work only with 2025?
@CarlosEpia Could you please leave a comment if this is still up to date or not? I would just like to make sure that we are not confused later on when we have a look at merged PRs. |
ClaraBuettner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please take a look at the comments :)
|
How is this PR related to #1368? |
The cause of the differences was basically that the function scale_prox2now was working wrongly, which produces different results for different MASTR versions. Fixed here: 389a367 |
Okay, so is it related to this PR, or was there already some progress with the problem described there? |
…1274-unify-and-update-to-latest-official-open_mastr

Fixes #1274 .
Necessary changes to replace mastr data from 2024-01-08 for 2025-02-09. It was already tested for SH and DE. The results look consistent. Additional fixes related to power plants were also included here.
🧑💻 Contributor Checklist
Before requesting a review, make sure you've completed all of the following:
(for more information on local test, check
toxin the Contributing section)(CI tests are automatically executed when creating a PR, you can see the results of the checks below)
(optional if no dataset changes are involved)
CHANGELOG.rstabout the changesAUTHORS.rstOptional:
🔍 Reviewer Checklist
During your review, please check the following:
CHANGELOG.rstupdated accordingly?📝 Additional Notes (optional)