Quick Answer
A solar roof obstruction register records each feature that can affect layout, access, drainage, structural review, safety, or installation: its location, source evidence, status, owner, and impact on the next decision. It separates a field observation from an approved design response.
A roof obstruction is not simply an object a designer draws around. It is a site condition that can change the layout, installation method, access, drainage, electrical route, safety plan, or need for qualified review. A register gives that condition a clear project identity. Instead of leaving a vent, skylight, parapet, damaged area, roof hatch, conduit, service path, or uncertain feature inside a photo folder, the team can see what was observed, what evidence supports it, and what decision remains.
This is desk research for solar professionals. It does not replace a roof inspection, structural assessment, engineering, manufacturer instructions, waterproofing expertise, site safety plan, local code, fire requirements, or authority decision. The necessary setback, access, and installation requirements depend on the jurisdiction, roof system, equipment, and project. Treat this as an evidence-control method rather than a universal layout rule.
Direct Answer
Give each material roof feature a register entry before relying on it in design. Record its location, description, source evidence, date, confidence status, affected decision, owner, and next action. A field observation can prompt a design response, but it does not itself approve that response.
Why Photos Alone Do Not Control Roof Information
Photos are valuable, especially when they preserve context, date, orientation, and a reference point. They become less useful when no one knows which roof plane they show, whether they were taken before or after a repair, or what the observer intended the next person to notice. A shared drive can hold dozens of images while the design team still lacks a reliable answer about a critical feature.
The NREL photovoltaics research collection offers broad PV context, but it cannot determine whether a particular feature is measured correctly, structurally relevant, accessible, or acceptable under local requirements. Project evidence needs a source and a boundary. A register turns a photo, drawing, imagery observation, survey measurement, or customer note into a question that someone can act on.
The most useful entries are decision-led. “Skylight near east array” is a starting point. “Skylight observed on east plane from survey photo 17; exact clearance to be verified before construction layout; design owner to assess” has an owner, evidence, and release effect.
Define What Counts as a Register Item
Do not create a register for every harmless roof detail. Include features or conditions that could change the work or require a deliberate confirmation. Examples may include roof penetrations, skylights, hatches, vents, drains, mechanical equipment, parapets, structural joints, areas of visible damage, access routes, nearby overhead conditions, existing PV equipment, cable routes, and zones with uncertain geometry.
| Register field | What to capture | Why it matters |
|---|---|---|
| Identifier and location | Roof plane, grid reference, drawing or photo reference | Lets design and field teams discuss the same item |
| Description | What was observed without assuming its technical effect | Separates fact from judgment |
| Source and date | Survey, current drawing, image, customer note, or observation | Shows evidence strength and currency |
| Status | Confirmed, planning assumption, or verification required | Makes uncertainty visible |
| Affected decision | Layout, access, routing, waterproofing, review, sequencing | Prevents a generic “note” from being ignored |
| Owner and next action | Who will measure, review, ask, or route it | Establishes accountability |
Avoid terms such as “clear” or “no issue” unless the record states who made that determination and on what basis. A field photograph may show a clear visual route without confirming roof condition, attachment feasibility, required access, drainage impact, or a local requirement.
Use Evidence Statuses That Match the Project Stage
At early design, satellite imagery or customer photographs may be enough to outline a preliminary layout. At construction release, the same evidence may be inadequate. The register should say which stage the evidence supports rather than forcing a false yes-or-no conclusion.
Use three practical statuses: supported for this decision, planning assumption, and required before later release. A dormer outline from imagery might be supported for screening but require field verification before a construction layout. A roof hatch shown in a current survey may still need an access review. The status describes the evidence boundary, not the importance of the feature.
The DOE Solar Energy Technologies Office is a helpful public resource about solar technologies. It does not provide a substitute for the evidence and qualified review required on a particular roof.
Connect the Register to the Layout, Not Just the Survey
Every material entry should point to the design output it affects. A roof-plane reference, layout markup, drawing callout, or photo annotation may be appropriate. The goal is traceability: a later reviewer should be able to see whether the register item was considered, deferred, or found to require a design change.
This is where Solar Designing can be useful for teams managing connected layouts and project inputs. Software can represent a feature in a model; it cannot confirm a roof condition, make a structural judgment, or determine compliance without the necessary project evidence and responsible review.
Turn Site Evidence Into a More Traceable Solar Design Record
Explore how SurgePV connects project inputs, layouts, Shadow Analysis, and customer-facing outputs around the same solar project.
Book a DemoDiscuss the survey-to-design handoff in a live walkthrough.
Do Not Treat a Sketch as a Construction Decision
A survey sketch is often a fast, useful communication tool. It is not automatically a final dimensioned design or instruction for an installer. If a feature changes array placement, attachment planning, electrical route, access, or another controlled part of the work, the appropriate design or review owner must incorporate or resolve it through the project process.
This distinction is especially important where a feature appears different in imagery, drawings, and field observation. The register can preserve all three sources, flag the conflict, and assign a resolution. Choosing the most convenient source without documenting why creates a quiet assumption that may surface only during installation.
Route Items by Effect, Not by Object Type
Two skylights may require different next actions. One may simply affect preliminary layout. Another may sit beside a required access path or reveal a roof condition that needs specialist review. The register should route the effect, not attach a fixed action to the noun.
| Item effect | A sensible next route |
|---|---|
| Changes preliminary panel area | Update the layout scenario and label it appropriately |
| Needs exact field dimensions | Assign survey measurement before the designated release |
| Affects roof condition or waterproofing question | Route to the competent roof or technical owner |
| Affects access or immediate site safety | Follow applicable site safety control and stop/escalate as needed |
| Conflicts with an existing drawing | Open a design question and preserve both evidence sources |
OSHA’s roofing guidance is a public safety reference, not a project-specific fall-protection plan. If an observed condition presents a safety concern, follow the applicable plan and responsible safety process. A register should make the concern visible; it does not authorize work near a hazard.
Review the Register at the Moments That Matter
Review entries at intake, after survey, before proposal release, before technical or construction issue, and when a field observation changes the available evidence. Not every item needs a meeting. A short review can clear routine entries and focus attention on the few conditions that could stop work or change the customer promise.
At each review, ask: Has new evidence changed the status? Has the layout or plan responded to the item? Is there a decision owner? Does the item affect what can be said to the customer or scheduled on site? If the answer is unknown, the entry is doing its job by revealing it.
Keep the Customer Conversation Specific
Do not say a layout “will fit” when the record shows that access, roof condition, dimensions, or another material feature is still open. Explain the stage: “This preliminary option uses available site information; we will confirm the listed roof features before a later release.” Specific qualification gives the customer a practical next step and protects the team from presenting an early model as settled construction scope.
Preserve the Evidence When the Item Is Closed
Closing an entry should not mean deleting its history. Record the resolution, the person or role that made it, the evidence reviewed, the affected design revision, and any limitation that still applies. A later service, warranty, or modification conversation may need to understand why a feature was handled in a particular way. The historical record should be easy to retrieve without being mistaken for the current construction instruction.
If the resolution relies on a later survey, photo, or specialist response, link that source rather than rewriting it as an unsupported summary. This keeps the register useful as an index of decisions instead of a second, conflicting version of the project file.
Improve Survey Requests From Actual Gaps
After a project reaches installation, review which register entries appeared too late. Repeated uncertainty around hatch locations may justify a better survey-photo request. Recurring conflicts between drawings and site conditions may signal an evidence-date issue. Do not label those observations as universal industry results. Use them to improve the next briefing question, survey annotation, or handoff rule.
Practical Next Steps
- Create an entry for every roof condition that could change layout, access, technical review, or installation planning.
- Link each entry to its evidence and the design output it affects.
- Mark what is confirmed, assumed, or required before the next release, then assign an owner.
Make Solar Site Inputs Easier to Follow Through Design
Book a free SurgePV demo to see Solar Designing, Shadow Analysis, generation modeling, and Solar Proposals in a connected workflow.
Book a Free DemoFrequently Asked Questions
What is a solar roof obstruction register?
It is a controlled list of roof features and conditions that can affect a PV project. Each entry identifies the location, evidence, status, affected decision, owner, and next action, so a site observation does not disappear into photos or personal memory.
Can satellite imagery confirm all roof obstructions for solar design?
No. Imagery can be useful for early modeling, but it may not show current dimensions, roof condition, access, concealed features, service routes, or local constraints. State what imagery supports and what still needs survey or qualified review.
Does every roof feature need an engineering review?
No. Route the item according to its actual effect and the applicable project requirements. Some features affect only preliminary layout; others may require a measurement, design change, safety control, roof specialist input, or another qualified review.
