| Reda & Andreas (2003), Solar Position Algorithm for Solar Radiation Applications, NREL/TP-560-34302 |
reference for the solar-position approach |
go/internal/sunpos |
| Spencer (1971) Fourier series (declination, equation of time, orbital distance) |
the simplified solar position actually implemented (~0.05°) |
go/internal/sunpos |
| Erbs, Klein & Duffie (1982) diffuse-fraction correlation |
GHI → DHI/DNI split when a provider publishes only global horizontal |
go/internal/sunpos, used by the forecast POA projection |
| WMO sunshine-duration threshold (120 W/m² direct beam) |
deriving cloudiness from STRÅNG sunshine minutes |
go/internal/strang |
| Yavuzdoğan (2023), Renewable Energy, doi:10.1016/j.renene.2023.119022 (the SPAN method) |
iterative RANSAC + DBSCAN roof-plane segmentation (method reimplemented; no code taken from the GPL plugin) |
roofmodel/ftw_roofmodel/segment.py |
| Lantmäteriet's Gauss conformal projection (Krüger series) publication |
direct SWEREF 99 TM ↔ WGS84 conversion instead of a pyproj dependency |
roofmodel/ftw_roofmodel/sweref.py |
| OGC 12-128r19 GeoPackage Encoding Standard, clause 2.1.3 |
decoding building-footprint GeoPackages without GDAL |
roofmodel/ftw_roofmodel/geopackage.py |
| OGC 06-103r4 Simple Features, clause 8.2 (WKB) |
geometry parsing inside those GeoPackages |
roofmodel/ftw_roofmodel/geopackage.py |
| COPC specification (copc.io) / ASPRS LAS 1.4 |
range-request windowed point-cloud reads |
roofmodel/ftw_roofmodel/pointcloud.py |
| STAC API specification |
catalog search contract (POST {base}/search), Lantmäteriet and any custom catalog |
roofmodel/ftw_roofmodel/geotorget.py |
| Recursive least squares (standard formulation) + Kalman smoothing |
the self-learning PV twin and load model |
go/internal/pvmodel, go/internal/loadmodel, go/internal/telemetry |
| Median / median-absolute-deviation robust statistics |
the STRÅNG performance-calibration factor that one snowy day must not move |
go/internal/pvperf |
The calculations in core and the roofmodel module rest on published papers,
standards and prior work, and today those references live only as scattered
code comments. Someone auditing the power math, or a reviewer asking "where
does this correlation come from?", has to grep for them. The docs tree should
carry one small page — say
docs/references.md— that lists eachcalculation's source next to where it is used, the same way
docs/site-convention.md
anchors the sign convention.
Rules to keep it useful:
entry point that implements it.
change (reviewable in the diff, like a changeset).
Draft inventory from the current code comments (starting point, not exhaustive)
go/internal/sunposgo/internal/sunposgo/internal/sunpos, used by the forecast POA projectiongo/internal/strangroofmodel/ftw_roofmodel/segment.pyroofmodel/ftw_roofmodel/sweref.pyroofmodel/ftw_roofmodel/geopackage.pyroofmodel/ftw_roofmodel/geopackage.pyroofmodel/ftw_roofmodel/pointcloud.pyPOST {base}/search), Lantmäteriet and any custom catalogroofmodel/ftw_roofmodel/geotorget.pygo/internal/pvmodel,go/internal/loadmodel,go/internal/telemetrygo/internal/pvperfIf the PV-forecast calibration work grows into a documented method of its own
(physical prior + statistical correction), the forecasting literature behind
that choice belongs on the same page — but only once code actually follows
it.