Parking #736 here as an idea rather than an open draft.
The idea: after the roof model derives a face's tilt and azimuth (#735), run
vostok ("Voxel Octree Solar
Toolkit", 3DGeo Heidelberg) against the same LiDAR tile the roof was segmented
from and attach a per-face shading_factor. The trees and neighbouring roofs
that cast the shadows are already in the point cloud, and a spruce to the south
can cost a real installation far more than a few degrees of azimuth ever will.
Why it is parked: vostok is GPL-3.0 C++ that the operator must clone and
build locally — FTW's licensing boundary means it can never be bundled,
redistributed or auto-installed, and asking a homeowner to stand up a C++
toolchain to get one shading number is too much hardship for the user the
feature is meant to serve. Worth reopening if vostok ships prebuilt binaries or
a permissively-licensed equivalent appears.
The implementation is complete on the branch, so picking this up again is a
rebase, not a rewrite:
Design decisions already worked out (keep these if reopened)
- The factor is a ratio of two runs — the same face computed with occlusion
geometry on and off. An absolute Wh/m²/day would depend on vostok's sky
model, its units and the year chosen; the ratio cancels all three and reads
as "fraction of open-sky irradiation this face actually receives".
- Absent ≠ 1.0. When vostok is not installed,
shading_factor is omitted,
not set to 1.0 — "we did not look" and "we looked and it is clear" are
different claims, and absence is the common case. Every failure path
(non-zero exit, missing output file, timeout) leaves the model unevaluated
with a stated reason and never fails the derive.
- The GPL boundary: separate process, files and a command line, no linking,
no code copied in either direction — mere aggregation. Never bundled, never
auto-installed.
- Tests: 15 shading tests against a stub of vostok's documented contract,
including the .sol file contract and a tilt/azimuth round-trip through the
segmenter. The one unverified spot: the .sol key names were never checked
against a real vostok build.
Parking #736 here as an idea rather than an open draft.
The idea: after the roof model derives a face's tilt and azimuth (#735), run
vostok ("Voxel Octree Solar
Toolkit", 3DGeo Heidelberg) against the same LiDAR tile the roof was segmented
from and attach a per-face
shading_factor. The trees and neighbouring roofsthat cast the shadows are already in the point cloud, and a spruce to the south
can cost a real installation far more than a few degrees of azimuth ever will.
Why it is parked: vostok is GPL-3.0 C++ that the operator must clone and
build locally — FTW's licensing boundary means it can never be bundled,
redistributed or auto-installed, and asking a homeowner to stand up a C++
toolchain to get one shading number is too much hardship for the user the
feature is meant to serve. Worth reopening if vostok ships prebuilt binaries or
a permissively-licensed equivalent appears.
The implementation is complete on the branch, so picking this up again is a
rebase, not a rewrite:
HuggeK:vostok-shadingDesign decisions already worked out (keep these if reopened)
geometry on and off. An absolute Wh/m²/day would depend on vostok's sky
model, its units and the year chosen; the ratio cancels all three and reads
as "fraction of open-sky irradiation this face actually receives".
shading_factoris omitted,not set to 1.0 — "we did not look" and "we looked and it is clear" are
different claims, and absence is the common case. Every failure path
(non-zero exit, missing output file, timeout) leaves the model unevaluated
with a stated reason and never fails the derive.
no code copied in either direction — mere aggregation. Never bundled, never
auto-installed.
including the
.solfile contract and a tilt/azimuth round-trip through thesegmenter. The one unverified spot: the
.solkey names were never checkedagainst a real vostok build.