Skip to content
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

Merged
merged 19 commits into from Mar 11, 2024
Merged

Conversation

AdamRJensen
Copy link
Member

@AdamRJensen AdamRJensen commented Feb 10, 2024

  • [ ] Closes #xxxx
  • I am familiar with the contributing guidelines
  • Tests added
  • Updates entries in docs/sphinx/source/reference for API changes.
  • Adds description and name entries in the appropriate "what's new" file in 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`).
  • New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
  • Pull request is nearly complete and ready for detailed review.
  • Maintainer: Appropriate GitHub Labels (including 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.

@AdamRJensen AdamRJensen added the io label Feb 10, 2024
@AdamRJensen AdamRJensen added this to the v0.10.4 milestone Feb 10, 2024
@AdamRJensen
Copy link
Member Author

@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?

@mikofski
Copy link
Member

I’m okay with including lxml. Another option is the built-in Python module xml.etree.ElementTree but I don’t recommend it.

@kandersolar
Copy link
Member

Can we get away with using the standard library by specifying parser='etree' in pd.read_xml? If not, I'm also fine with adding lxml to the optional dependencies.

@AdamRJensen
Copy link
Member Author

Can we get away with using the standard library by specifying parser='etree' in pd.read_xml? If not, I'm also fine with adding lxml to the optional dependencies.

Works like a charm! Thanks 😄

@AdamRJensen AdamRJensen added the remote-data triggers --remote-data pytests label Feb 12, 2024
Copy link
Member

@kandersolar kandersolar left a 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

pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Feb 12, 2024
@AdamRJensen AdamRJensen marked this pull request as ready for review February 12, 2024 23:01
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Feb 12, 2024
@AdamRJensen
Copy link
Member Author

AdamRJensen commented Feb 12, 2024

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:

 {'PT05M': 'MIN_5', 'PT10M': 'MIN_10', 'PT15M': 'MIN_15', 'PT30': 'MIN_30', 'PT60M': 'HOURLY', 'PT1H': 'HOURLY', 'P1D': 'DAILY', 'P1M': 'MONTHLY', 'P1Y': 'YEARLY'}

Thoughts on "summarization" vs "time_step"?

Copy link
Member

@kandersolar kandersolar left a 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.

pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/tests/iotools/test_solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
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.', ''))
Copy link
Member

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).

Copy link
Member Author

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.

Copy link
Member

@kandersolar kandersolar left a 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!

pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solcast.py Show resolved Hide resolved
pvlib/tests/iotools/test_solargis.py Outdated Show resolved Hide resolved
pvlib/iotools/solargis.py Outdated Show resolved Hide resolved
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Mar 9, 2024
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Mar 9, 2024
@AdamRJensen AdamRJensen marked this pull request as draft March 9, 2024 13:55
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Mar 9, 2024
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Mar 9, 2024
@AdamRJensen AdamRJensen added remote-data triggers --remote-data pytests and removed remote-data triggers --remote-data pytests labels Mar 9, 2024
@AdamRJensen AdamRJensen marked this pull request as ready for review March 9, 2024 15:41
Copy link
Member

@kandersolar kandersolar left a 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!

@kandersolar kandersolar merged commit 3c7b5da into pvlib:main Mar 11, 2024
28 of 29 checks passed
@AdamRJensen AdamRJensen deleted the solargis branch March 12, 2024 08:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
io remote-data triggers --remote-data pytests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants