-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add get_solargis iotools function #1969
Conversation
@kandersolar The data returned from Solargis is in XML format, thus the lxml python package is required. Can that be added to the pvlib's list of optional packages? |
I’m okay with including lxml. Another option is the built-in Python module xml.etree.ElementTree but I don’t recommend it. |
Can we get away with using the standard library by specifying |
Works like a charm! Thanks 😄 |
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.
A few initial comments
One things I don't like is the summarization naming (e.g., '5_MIN', 'HOURLY'). For the CAMS functions we use the name "time_step". Also, perhaps we should allow for the time steps to follow the ISO 8601 naming convention by mapping with this dictionary:
Thoughts on "summarization" vs "time_step"? |
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.
Thoughts on "summarization" vs "time_step"?
I do not like summarization
. get_solaranywhere
uses time_resolution
(int). get_psm3
uses period
(int). Of these, I like the time_resolution
name best.
For the ISO 8601 durations idea, I mildly prefer specifying an integer number of minutes, but I don't feel strongly about it.
meta[key] = ':'.join(line.split(':')[1:]) | ||
meta['latitude'] = float(meta['latitude']) | ||
meta['longitude'] = float(meta['longitude']) | ||
meta['altitude'] = float(meta.pop('elevation').replace('m a.s.l.', '')) |
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.
It would be great to include the data version in the returned metadata too. Unfortunately it can't be extracted based on colons as you've done for the other fields (it looks like '#Output from the climate database Solargis v2.2.46
).
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 agree it would be nice, but judging it to be out of scope for now.
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.
A few comments, and I think the tests need some updates. Otherwise looking pretty good to me!
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.
We need to update the minimum versions in the benchmarks too now, but I'll do that separately. Thanks @AdamRJensen!
[ ] Closes #xxxxdocs/sphinx/source/reference
for API changes.docs/sphinx/source/whatsnew
for all changes. Includes link to the GitHub Issue with:issue:`num`
or this Pull Request with:pull:`num`
. Includes contributor name and/or GitHub username (link with:ghuser:`user`
).remote-data
) and Milestone are assigned to the Pull Request and linked Issue.This PR adds a fetching function for Solargis irradiance data. Given that such functions for SolarAnywhere and Solcast has been added in the previous release, it seems fitting to also have it for Solargis.