-
Notifications
You must be signed in to change notification settings - Fork 173
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
Potential bug in network parameter, num_parallel or length #862
Comments
Thanks for sharing @pz-max! Agree that the result is quite surprising. When doing grid validation for Central and Western Asia, we found some discrepancies, but they have never be as high as more than eight times... My feeling is that it would be good:
|
One extra point: |
Here is a follow on @ekatef suggestions. Here is a voltage comparison plot between OSM and ENTSOE Using log transformation on the y-axis to scale the data Here is also a more detailed country stat comparison for Tw/Km Using log transformation on the y-axis to scale the data One of the things I noticed is that the country code with LU is missing data in the entsoe network. |
Thanks @GbotemiB , regarding units.
|
@GbotemiB Amazing plots! 🤩 @pz-max agree that comparison for line lengths would be highly interesting. My feeling is that is would be great if we could provide Emmanuel with clean_osm_data. Actually, I hope that inter-comparison results would also look nicer for lengths :D |
@GbotemiB can you create a repo with the notebook such that we can review the code easily? (Meaning the data needs to be uploaded somewhere for the notebook too) |
@GbotemiB Ouch... I'd say, the result is quite surprising 😄 Great to have cross-comparison Agree with @pz-max that your comparison work would be a great contribution to documentation repo. Would you mind to fork it and create a PR with your notebook? |
I personally believe that we may revise and investigate the conversion of the raw osm data into the cleaning phase as well. As test cases AT and MK may be good to test given the errors. |
@davide-f my feeling is that it would be perfect :) There are still some some validations for cleaned OSM data, while not sure anybody looked into effects of the cleaning procedure itself. |
Here you can find selected folders of "resources" for the selected countries: In particular, it contains folders shapes, osm and base_network that should be all that's needed. |
@davide-f Fantastic, thank you very much! 😄 |
@GbotemiB amazing result! 🎉 🎉 🎉 My feeling is that the line length for ENTSO is lower than for OSM data due to the coastline paradox. Not sure yet which exactly implication does it has for power flow calculations. Actually, |
After doing a bit of cleaning on the data with @ekatef .
|
The numbers to me do not look bad at all! To test if the issue is the spatial resolution, the geometries may be simplified using simplify (https://wichita.ogs.ou.edu/OpenLayers-2.12/examples/simplify-linestring.html) on the geometries using a tolerange similar to the one of entso-e and see if numbers match better. Moreover, as a second comparison, may be good to check the total TW by voltage, calculated as: s_nom line , for lines beyond 10km. |
Thanks a lot @davide-f! My feeling is that the hint with simplification may be very helpful 🙂 It looks like Douglas–Peucker is exactly what we need here. @GbotemiB this algorithm is available in geopandas as |
We thought the OSM data is doing quite well in EU looking at:
Reported by Tom B:
PyPSA-Eur (entsoe) is MUCH closer to official statistics (which here include Turkey, unlike PyPSA-Eur): https://eepublicdownloads.entsoe.eu/clean-documents/Publications/Statistics/Factsheet/entsoe_sfs2021_web.pdf
PyPSA-Eur 159,000 for 380 kV is much closer to official 186,000 than OSM's 290,000.
Ditto for 220+300: our 125,000 km is much closer to official 131,000 km than OSM's 930,000 km.
TODO:
Two possible reasons for big OSM error:
The text was updated successfully, but these errors were encountered: