-
Notifications
You must be signed in to change notification settings - Fork 16
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
Converting Shiny weather data with the Metadata processor: bugs and issues #687
Comments
Thanks Csilla, |
Response to #687 and minor fix in SUEWS DB Prepare
Both issues should now be fixed. Check out new development release. |
Fantastic, thank you! |
The attempt to install the development release lands in a SyntaxError: (f-string: unmatched '[') Here is the full error message :: SyntaxError: f-string: unmatched '[' Environment :: |
Try now. |
Unfortunately, I got the same exact error. |
Ok, Let us know if you find a solution for Mac. |
Hi Team,
There comes my concise write-up.
Thanks for all the work!
Best,
Csilla
Shiny weather data offers four output formats, out of which two could be relevant to UMEP.
1 .CSV
At the moment, under all my os-QGIS variations, loading the csv file is not possible. I receive the error of "If invalid data was detected such as strings or other non-numrical characters, these data points could result in that the MetdataProcessor will fail to create your UMEP-formatted inputdata." and the interface remains locked (without the possibility to assign the column names to various meteorological parameters).
This is most likely caused my the formatting of the file that starts with 11 lines of header lines that begin with a hash sign. Unfortunately, setting the 'Number of header lines' in the interface to 12 or higher does not resolve the issue. See attached screenshot.
Attached is a csv file for reference:
Chicago2020LT.csv
2 .EPW
The epw conversion works, apart from the hard-coded year of 1985 (noted earlier). While one could replace the year in the resultant file with the help of a text editor, the problem becomes more complex when the supplied Actual Meteorological Year (AMY) is a leap year. Put simply, the current code results in duplicate datetime labels, when leap year is fed in, eventually, causing a 24-hour shift in the data following the leap day. Fixing this can be challenging to those without solid Excel or scripting skills.
Attached is an UMEP-converted epw file for reference:
Chicago2020LTepw.txt
The text was updated successfully, but these errors were encountered: