You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orientation (azimuth angle) of the (fixed) plane. 0=south, 90=west,
-90: east. Ignored for tracking systems.
This inconsistency is a shame. However, I don't see any way to switch it to pvlib's convention without a hard break, which is also a shame. I wonder how others view the cost/benefit analysis here.
Since get_pvgis_hourly is only using surface_azimuth to pass a value to a pvgis keyword aspect, we could add aspect with the South=0 convention and deprecate surface_azimuth as is. Then later, we can deprecate aspect and add surface_azimuth back with its pvlib meaning. Now that I write that out, seems better just to make the breaking change.
This issue discusses that surface_azimuth in get_pvgis_hourly should be changed to clockwise from north, but the documentation in pvgis.py mentions counter-clockwise from north, even though the implementation 'aspect': surface_azimuth-180 matches what was discussed in this issue.
I would have a PR at the ready if this is not a misunderstanding on my side.
Nearly everything in pvlib represents azimuth angles as values in [0, 360) clockwise from north, except
pvlib.iotools.get_pvgis_hourly
:pvlib-python/pvlib/iotools/pvgis.py
Lines 79 to 81 in 3def7e3
This inconsistency is a shame. However, I don't see any way to switch it to pvlib's convention without a hard break, which is also a shame. I wonder how others view the cost/benefit analysis here.
See also #1395 (comment)
The text was updated successfully, but these errors were encountered: