Why roof pitch and orientation matter for PV
Reliable PV planning depends on how each roof plane actually sits in space: its pitch relative to horizontal, its orientation, and how rooftop structures reduce usable module area.
The European Commission JRC documentation behind PVGIS separates these parameters clearly. Slope is the inclination of the plane, while azimuth describes its orientation relative to south. Those values directly affect yield calculations, shading simulation, and realistic module placement.
Errors often start before any simulation begins. If roof pitch is guessed, read from a single photo, or transferred into planning software without a clear reference system, the layout and production estimate become only apparently precise.
For solar installers and planners, the real question is not whether the roof was photographed, but whether a trustworthy 3D geometry exists from which pitch, orientation, and true roof area can be derived.
Important distinction
An orthophoto shows the roof from above, but it does not automatically encode roof pitch. You need a 3D surface, roof plane model, or properly reconstructed geometry.
Pitch, orientation, area: the clean definitions
Roof pitch is the angle between the roof plane and the horizontal plane. In surface analysis this corresponds to slope.
Roof orientation is the direction a plane faces. In GIS this is often called aspect. ArcGIS defines aspect as the downslope compass direction of a surface.
True roof area is not the top-down projection. It is the actual inclined surface area, which matters for module counts and material planning.
| Topic | Formula / derivation | Practical use |
|---|---|---|
| Roof pitch from rise and horizontal run | alpha = arctan(Delta h / horizontal run) | Useful when ridge and eave lines are known from the 3D model. |
| True roof area from projected area | A_true = A_projected / cos(alpha) | Important for module count and quantity takeoff. |
| Roof orientation | derived from plane normal or surface aspect | Must be translated consistently into the azimuth convention used by PV software. |
PVGIS and GIS are not using the same angle language
PVGIS expresses azimuth relative to south, while GIS tools often express aspect as a compass direction from north. The conversion should be documented in the handoff.
How drone photogrammetry produces the values
The robust path is a photogrammetric 3D model, not a single image. A drone captures overlapping photos, software reconstructs a georeferenced surface, and roof planes are then segmented and evaluated as surfaces.
DJI specifies RTK positioning accuracy for the Mavic 3 Enterprise at 1 cm + 1 ppm horizontal and 1.5 cm + 1 ppm vertical under RTK fix. That is useful input quality information, but it is not a blanket guarantee for final roof-plane accuracy.
DJI also states an absolute horizontal photogrammetric accuracy of roughly 5 cm for the Phantom 4 RTK under specific conditions. Such figures are helpful indicators, but final project quality still depends on image geometry, processing, and verification against independent checks.
- 01
Plan the flight for the required deliverable
Altitude, overlap, and viewing angle should match the level of roof detail and rooftop complexity required by the downstream workflow.
- 02
Generate a 3D roof surface
Pitch and orientation require a mesh, point cloud, or roof plane model. A 2D orthophoto alone is not enough.
- 03
Segment roof sub-surfaces
Main roof planes, dormers, parapets, and extensions should be separated so each keeps its own pitch and orientation.
- 04
Compute pitch and aspect per surface
The software derives the angle to horizontal and the direction the surface faces from the reconstructed geometry.
- 05
Check quality against independent references
Where accuracy matters, use GCPs or checkpoints so the final values are not accepted blindly.
- 06
Export in a PV- and CAD-ready format
Provide a roof model, orthophoto, and documented angle logic so planning teams can continue without reinterpretation.
What level of accuracy is realistic
RTK positioning, final model accuracy, and derived roof-plane values are related, but not identical. Pitch and orientation quality also depend on GSD, overlap, camera calibration, and clean roof-plane segmentation.
PIX4D recommends a minimum of three GCPs to scale, rotate, and locate a model, and generally recommends five to ten GCPs distributed across the site with additional checkpoints for quality assessment.
For formal product accuracy assessment, the updated ASPRS 2024 standard uses a minimum of 30 checkpoints. Small roof projects often do not need a full standards-driven assessment, but the principle remains the same: independent checks matter.
| Method | Data basis | Strengths | Limits |
|---|---|---|---|
| Rough estimate or sales sketch | visual estimation or legacy drawings | fast and inexpensive | not reliable enough for technical PV planning on complex roofs |
| Phone app or handheld inclinometer | single on-site reading | useful for spot checks | does not capture full roof geometry or multiple sub-surfaces |
| Orthophoto without 3D model | 2D top-down imagery | good for visible rooftop obstacles and planimetric checks | cannot robustly deliver roof pitch or true surface area |
| RTK photogrammetry with 3D roof model | overlapping imagery plus reconstructed 3D geometry | consistent sub-surfaces, pitch, orientation, and area in one model | still requires verification and careful processing |
RTK does not remove the need for QA
RTK improves the image georeferencing, but poor overlap, weak reconstruction, or bad roof-plane segmentation can still degrade the final result.
What PVGIS and PV planning actually need
PVGIS explicitly works with a defined slope and azimuth for fixed systems. On existing roofs, these are measured building parameters, not theoretical optimization values.
In real planning workflows, one angle for the whole building is rarely enough. Installers need separate roof planes with their own pitch, orientation, usable area, and rooftop obstacles.
True surface area matters as much as angle. If only the projected area is used, module counts and material estimates are distorted, especially on steeper roofs.
For software handoff, angle convention, coordinate reference, and roof-plane boundaries should be documented so there is no ambiguity between GIS, CAD, and PV tools.
Typical practical error sources
The most common mistake is treating top-down area as true roof area. That underestimates usable surface on pitched roofs.
Another common issue is mixing angle conventions. GIS aspect and PV azimuth are related but not always expressed in the same reference system.
A third error is collapsing a complex roof into one average plane. Dormers, parapets, or extensions often require separate treatment.
Finally, visually convincing models can still be geometrically weak. Independent checkpoints or reference checks remain important.
Which outputs are useful for installers and planners
A practical package usually combines a georeferenced orthophoto with a 3D roof model, documented roof-plane pitch and orientation values, and exportable geometry for downstream planning.
If CAD or BIM workflows follow, the handoff should include not just visuals but structured geometry and documented angle logic.
For Voxelia-type projects, this replaces repeated manual measurement with a shared geometric basis for sales, yield estimation, detailed planning, and client alignment.
Useful minimum package
Orthophoto, 3D roof model, documented roof-plane values, and a short note on the data basis are usually the minimum useful set.